On 06/27/2015 08:32 AM, Kazutoshi Satoda wrote:
> I have some questions on the paper.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.html
>
> How did it taken by the committee?
> Rejected or accepted? I couldn't find any mention about this paper
> even in this very detailed trip report.

The paper was discussed in the core working group.  It needs a bit
more polishing before it can go to adoption by the full committee.
My feeling was that the general sentiment in the room (NOT the full
committee) was positive about the direction.  This paper essentially
codifies that you can't access a complete object using a pointer
that pointed originally to some other complete object, which is
very useful for optimizers.

If an update comes along for Kona, I'd expect the paper to be
adopted there and then.

> https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/
> I'm feeling like that the change in the paper will make new
> incompatibilities between C and C++, and then that would be pointed out
> by the committee.

There was no mention of C incompatibilities (that I remember).  In practice,
reasonable programs will be entirely unaffected by this change.

> What the changes do for reference members?
> There is a change addressing the issue with const members (Change in 3.8
> (basic.life) paragraph 9). But it seems that replacement of class
> objects containing reference members (the title issue) is still not
> allowed because 3.8 [basic.life] paragraph 7 is not changed. Changes on
> pointer comparisons seems like irrelevant to the issue.

I've e-mailed the paper author about that.

Thanks,
Jens

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015/06/28 3:36, Jens Maurer wrote:
> On 06/27/2015 08:32 AM, Kazutoshi Satoda wrote:
>> I have some questions on the paper.
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.html
>>=20
>> How did it taken by the committee?
....
> The paper was discussed in the core working group.  It needs a bit
> more polishing before it can go to adoption by the full committee.
> My feeling was that the general sentiment in the room (NOT the full
> committee) was positive about the direction.  This paper essentially
> codifies that you can't access a complete object using a pointer
> that pointed originally to some other complete object, which is
> very useful for optimizers.

I think it's fine on that essential point.

> If an update comes along for Kona, I'd expect the paper to be
> adopted there and then.
....
>> I'm feeling like that the change in the paper will make new
>> incompatibilities between C and C++, and then that would be pointed out
>> by the committee.
>=20
> There was no mention of C incompatibilities (that I remember).  In practi=
ce,
> reasonable programs will be entirely unaffected by this change.

Then I'll add some more details about my concerns bellow.


First concern with C incompatibility is that the paper says "malloc
alone is not sufficient to create an object" as "the status quo". But
in C, malloc (or other allocation functions) is the only way to create
objects with dynamic storage duration. If changes (proposed and
foreseen) based on that "status quo" are accepted, many C programs will
be seen invalid with C++ compiler and may be broken silently.


Second one is that the paper seems banning casts between pointer to a
class and pointer to its first subobject. There seems to be some C
programs that emulate class inheritance with such casts. For example:
https://stackoverflow.com/questions/415452/object-orientation-in-c/415536#4=
15536
> struct base
> {
>     /* base class members */
> };
>
> struct derived
> {
>     struct base super;
>     /* derived class members */
> };
>
> struct derived d;
> struct base *base_ptr =3D (struct base *)&d;  // upcast
> struct derived *derived_ptr =3D (struct derived *)base_ptr;  // downcast

I think these are valid C program, and C++ also allow them with some
special rules to keep compatibility with C. The paper seems like
removing one of them.

"Change in 3.9.2 (basic.compound) paragraph 3" deletes this part of
the current standard.
> If an object of type T is located at an address A, a pointer of type cv
> T* whose value is the address A is said to point to that object,
> regardless of how the value was obtained.

"Change in 9.2 class.mem paragraph 19" adds a note that is presumably
derived from the above deletion.
> If a standard-layout class object has any non-static data members, its
> address is the same as the address of its first non-static data member.
....
> [ Note  Nonetheless, if a pointer to the object is cast to a pointer to
> the type of its first subobject (or vice versa), the resulting pointer do=
es
> not point to the subobject and can not be used to access it. =E2=80=94end=
 note ]

With these changes, the result of "upcast"/"downcast" in the above
quoted code no longer "points to" the subobject nor the enclosing object,
thus unusable to access them.


I remember some points like these were discussed in SG12, but I can't
find the conclusion.
http://www.open-std.org/pipermail/ub/2014-January/thread.html
Did the discussion continued in other place and reached to a conclusion?


>> What the changes do for reference members?
....
> I've e-mailed the paper author about that.

Thank you.

Is it good to send CC to the e-mail address in paper to post about a
paper? (I think it is good, but I forgot to do that this time.)


--=20
k_satoda

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--90e6ba475dcfbb8d1105198eaf70
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 27, 2015 at 8:52 PM, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
wrote:

> On 2015/06/28 3:36, Jens Maurer wrote:
> > On 06/27/2015 08:32 AM, Kazutoshi Satoda wrote:
> >> I have some questions on the paper.
> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.html
>

Regarding 3.8/7: I don't see that any changes are required there. It
continues to be the case that replacing an object of a class with reference
or const members invalidates all pointers, references, and names that refer
to the original object, in the sense that they cannot be used to access the
new object. Accessing the new object starting from an old
pointer/reference/name requires use of std::launder.

>> How did it taken by the committee?
> ...
> > The paper was discussed in the core working group.  It needs a bit
> > more polishing before it can go to adoption by the full committee.
> > My feeling was that the general sentiment in the room (NOT the full
> > committee) was positive about the direction.  This paper essentially
> > codifies that you can't access a complete object using a pointer
> > that pointed originally to some other complete object, which is
> > very useful for optimizers.
>
> I think it's fine on that essential point.
>
> > If an update comes along for Kona, I'd expect the paper to be
> > adopted there and then.
> ...
> >> I'm feeling like that the change in the paper will make new
> >> incompatibilities between C and C++, and then that would be pointed ou=
t
> >> by the committee.
> >
> > There was no mention of C incompatibilities (that I remember).  In
> practice,
> > reasonable programs will be entirely unaffected by this change.
>
> Then I'll add some more details about my concerns bellow.
>
>
> First concern with C incompatibility is that the paper says "malloc
> alone is not sufficient to create an object" as "the status quo". But
> in C, malloc (or other allocation functions) is the only way to create
> objects with dynamic storage duration. If changes (proposed and
> foreseen) based on that "status quo" are accepted, many C programs will
> be seen invalid with C++ compiler and may be broken silently.
>

This paper does not change anything here. In C++, malloc has never created
an object because [intro.object]/1 says that an object is *only* created by
a new-expression, declaration, or when an implementation creates a
temporary object (malloc is none of these). I agree that this is a problem,
and it's very common to see programs do this:

  struct TrivialThing { int a, b, c; };
  TrivialThing *p =3D reinterpret_cast<TrivialThing*>(malloc());
  p->a =3D 0; // UB, no object of type TrivialThing here

I'll reiterate what the paper says: there is no change to the status quo
here; the standard previously said this was UB, and still does. Fixing this
(if the committee agrees that it is a bug) should be done by a separate
paper.

Second one is that the paper seems banning casts between pointer to a
> class and pointer to its first subobject. There seems to be some C
> programs that emulate class inheritance with such casts. For example:
>
> https://stackoverflow.com/questions/415452/object-orientation-in-c/415536=
#415536
> > struct base
> > {
> >     /* base class members */
> > };
> >
> > struct derived
> > {
> >     struct base super;
> >     /* derived class members */
> > };
> >
> > struct derived d;
> > struct base *base_ptr =3D (struct base *)&d;  // upcast
> > struct derived *derived_ptr =3D (struct derived *)base_ptr;  // downcas=
t
>
> I think these are valid C program, and C++ also allow them with some
> special rules to keep compatibility with C. The paper seems like
> removing one of them.
>

This was the subject of some debate. The previous draft of the paper
intended to allow such casts in the cases where the standard guaranteed the
addresses are the same (indeed, that seemed to be the purpose of such
guarantees). We backed off this when it was observed that an existing C++
optimizer was already optimizing on the basis of such casts being invalid,
based on a (reasonable) reading of the current wording of the standard.

This probably warrants more debate by CWG. If possible, I'd like to
guarantee that casting between a pointer-to-standard-layout-class and its
first element gives a usable pointer value, and likewise for casting
between a pointer to an array and its first element and for casting between
a pointer to a union and any element type. This seems to be the intent of
the current standard wording, even if a strict interpretation of the words
could give another conclusion.


> "Change in 3.9.2 (basic.compound) paragraph 3" deletes this part of
> the current standard.
> > If an object of type T is located at an address A, a pointer of type cv
> > T* whose value is the address A is said to point to that object,
> > regardless of how the value was obtained.
>
> "Change in 9.2 class.mem paragraph 19" adds a note that is presumably
> derived from the above deletion.
> > If a standard-layout class object has any non-static data members, its
> > address is the same as the address of its first non-static data member.
> ...
> > [ Note  Nonetheless, if a pointer to the object is cast to a pointer to
> > the type of its first subobject (or vice versa), the resulting pointer
> does
> > not point to the subobject and can not be used to access it. =E2=80=94e=
nd note ]
>
> With these changes, the result of "upcast"/"downcast" in the above
> quoted code no longer "points to" the subobject nor the enclosing object,
> thus unusable to access them.
>
>
> I remember some points like these were discussed in SG12, but I can't
> find the conclusion.
> http://www.open-std.org/pipermail/ub/2014-January/thread.html
> Did the discussion continued in other place and reached to a conclusion?
>
>
> >> What the changes do for reference members?
> ...
> > I've e-mailed the paper author about that.
>
> Thank you.
>
> Is it good to send CC to the e-mail address in paper to post about a
> paper? (I think it is good, but I forgot to do that this time.)
>

This author reads std-proposals :) But yes, as general advice, you should
contact the author of the paper when providing feedback; that's why the
papers contain an email address for the author.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--90e6ba475dcfbb8d1105198eaf70
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, Jun 27, 2015 at 8:52 PM, Kazutoshi Satoda <span dir=3D"ltr">&lt;<a href=
=3D"mailto:k_satoda@f2.dion.ne.jp" target=3D"_blank">k_satoda@f2.dion.ne.jp=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">O=
n 2015/06/28 3:36, Jens Maurer wrote:<br>
&gt; On 06/27/2015 08:32 AM, Kazutoshi Satoda wrote:<br>
&gt;&gt; I have some questions on the paper.<br>
&gt;&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015=
/n4430.html" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2015/n4430.html</a><br></span></blockquote><div><=
br></div><div>Regarding 3.8/7: I don&#39;t see that any changes are require=
d there. It continues to be the case that replacing an object of a class wi=
th reference or const members invalidates all pointers, references, and nam=
es that refer to the original object, in the sense that they cannot be used=
 to access the new object. Accessing the new object starting from an old po=
inter/reference/name requires use of std::launder.</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D"">&gt;&gt; How did it taken by th=
e committee?<br>
</span>...<br>
<span class=3D"">&gt; The paper was discussed in the core working group.=C2=
=A0 It needs a bit<br>
&gt; more polishing before it can go to adoption by the full committee.<br>
&gt; My feeling was that the general sentiment in the room (NOT the full<br=
>
&gt; committee) was positive about the direction.=C2=A0 This paper essentia=
lly<br>
&gt; codifies that you can&#39;t access a complete object using a pointer<b=
r>
&gt; that pointed originally to some other complete object, which is<br>
&gt; very useful for optimizers.<br>
<br>
</span>I think it&#39;s fine on that essential point.<br>
<span class=3D""><br>
&gt; If an update comes along for Kona, I&#39;d expect the paper to be<br>
&gt; adopted there and then.<br>
</span>...<br>
<span class=3D"">&gt;&gt; I&#39;m feeling like that the change in the paper=
 will make new<br>
&gt;&gt; incompatibilities between C and C++, and then that would be pointe=
d out<br>
&gt;&gt; by the committee.<br>
&gt;<br>
&gt; There was no mention of C incompatibilities (that I remember).=C2=A0 I=
n practice,<br>
&gt; reasonable programs will be entirely unaffected by this change.<br>
<br>
</span>Then I&#39;ll add some more details about my concerns bellow.<br>
<br>
<br>
First concern with C incompatibility is that the paper says &quot;malloc<br=
>
alone is not sufficient to create an object&quot; as &quot;the status quo&q=
uot;. But<br>
in C, malloc (or other allocation functions) is the only way to create<br>
objects with dynamic storage duration. If changes (proposed and<br>
foreseen) based on that &quot;status quo&quot; are accepted, many C program=
s will<br>
be seen invalid with C++ compiler and may be broken silently.<br></blockquo=
te><div><br></div><div>This paper does not change anything here. In C++, ma=
lloc has never created an object because [intro.object]/1 says that an obje=
ct is *only* created by a new-expression, declaration, or when an implement=
ation creates a temporary object (malloc is none of these). I agree that th=
is is a problem, and it&#39;s very common to see programs do this:</div><di=
v><br></div><div>=C2=A0 struct TrivialThing { int a, b, c; };</div><div>=C2=
=A0 TrivialThing *p =3D reinterpret_cast&lt;TrivialThing*&gt;(malloc());</d=
iv><div>=C2=A0 p-&gt;a =3D 0; // UB, no object of type TrivialThing here</d=
iv><div>=C2=A0</div><div>I&#39;ll reiterate what the paper says: there is n=
o change to the status quo here; the standard previously said this was UB, =
and still does. Fixing this (if the committee agrees that it is a bug) shou=
ld be done by a separate paper.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
Second one is that the paper seems banning casts between pointer to a<br>
class and pointer to its first subobject. There seems to be some C<br>
programs that emulate class inheritance with such casts. For example:<br>
<a href=3D"https://stackoverflow.com/questions/415452/object-orientation-in=
-c/415536#415536" rel=3D"noreferrer" target=3D"_blank">https://stackoverflo=
w.com/questions/415452/object-orientation-in-c/415536#415536</a><br>
&gt; struct base<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 =C2=A0/* base class members */<br>
&gt; };<br>
&gt;<br>
&gt; struct derived<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 =C2=A0struct base super;<br>
&gt;=C2=A0 =C2=A0 =C2=A0/* derived class members */<br>
&gt; };<br>
&gt;<br>
&gt; struct derived d;<br>
&gt; struct base *base_ptr =3D (struct base *)&amp;d;=C2=A0 // upcast<br>
&gt; struct derived *derived_ptr =3D (struct derived *)base_ptr;=C2=A0 // d=
owncast<br>
<br>
I think these are valid C program, and C++ also allow them with some<br>
special rules to keep compatibility with C. The paper seems like<br>
removing one of them.<br></blockquote><div><br></div><div>This was the subj=
ect of some debate. The previous draft of the paper intended to allow such =
casts in the cases where the standard guaranteed the addresses are the same=
 (indeed, that seemed to be the purpose of such guarantees). We backed off =
this when it was observed that an existing C++ optimizer was already optimi=
zing on the basis of such casts being invalid, based on a (reasonable) read=
ing of the current wording of the standard.</div><div><br></div><div>This p=
robably warrants more debate by CWG. If possible, I&#39;d like to guarantee=
 that casting between a pointer-to-standard-layout-class and its first elem=
ent gives a usable pointer value, and likewise for casting between a pointe=
r to an array and its first element and for casting between a pointer to a =
union and any element type. This seems to be the intent of the current stan=
dard wording, even if a strict interpretation of the words could give anoth=
er conclusion.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&quot;Change in 3.9.2 (basic.compound) paragraph 3&quot; deletes this part =
of<br>
the current standard.<br>
&gt; If an object of type T is located at an address A, a pointer of type c=
v<br>
&gt; T* whose value is the address A is said to point to that object,<br>
&gt; regardless of how the value was obtained.<br>
<br>
&quot;Change in 9.2 class.mem paragraph 19&quot; adds a note that is presum=
ably<br>
derived from the above deletion.<br>
&gt; If a standard-layout class object has any non-static data members, its=
<br>
&gt; address is the same as the address of its first non-static data member=
..<br>
....<br>
&gt; [ Note=C2=A0 Nonetheless, if a pointer to the object is cast to a poin=
ter to<br>
&gt; the type of its first subobject (or vice versa), the resulting pointer=
 does<br>
&gt; not point to the subobject and can not be used to access it. =E2=80=94=
end note ]<br>
<br>
With these changes, the result of &quot;upcast&quot;/&quot;downcast&quot; i=
n the above<br>
quoted code no longer &quot;points to&quot; the subobject nor the enclosing=
 object,<br>
thus unusable to access them.<br>
<br>
<br>
I remember some points like these were discussed in SG12, but I can&#39;t<b=
r>
find the conclusion.<br>
<a href=3D"http://www.open-std.org/pipermail/ub/2014-January/thread.html" r=
el=3D"noreferrer" target=3D"_blank">http://www.open-std.org/pipermail/ub/20=
14-January/thread.html</a><br>
Did the discussion continued in other place and reached to a conclusion?<br=
>
<span class=3D""><br>
<br>
&gt;&gt; What the changes do for reference members?<br>
</span>...<br>
<span class=3D"">&gt; I&#39;ve e-mailed the paper author about that.<br>
<br>
</span>Thank you.<br>
<br>
Is it good to send CC to the e-mail address in paper to post about a<br>
paper? (I think it is good, but I forgot to do that this time.)<br></blockq=
uote><div><br></div><div>This author reads std-proposals :) But yes, as gen=
eral advice, you should contact the author of the paper when providing feed=
back; that&#39;s why the papers contain an email address for the author.</d=
iv></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--90e6ba475dcfbb8d1105198eaf70--

.

On 2015/06/28 16:11, Richard Smith wrote:
> Regarding 3.8/7: I don't see that any changes are required there. It
> continues to be the case that replacing an object of a class with reference
> or const members invalidates all pointers, references, and names that refer
> to the original object, in the sense that they cannot be used to access the
> new object. Accessing the new object starting from an old
> pointer/reference/name requires use of std::launder.

OK I got the idea of that. I should re-read the paper. Thank you.

If possible, I want to see a newer version of the paper or list of
feedbacks already given.

>> First concern with C incompatibility is that the paper says "malloc
>> alone is not sufficient to create an object" as "the status quo". But
....
> This paper does not change anything here. In C++, malloc has never created
> an object because [intro.object]/1 says that an object is *only* created by
> a new-expression, declaration, or when an implementation creates a
> temporary object (malloc is none of these). I agree that this is a problem,
> and it's very common to see programs do this:
>
>   struct TrivialThing { int a, b, c; };
>   TrivialThing *p = reinterpret_cast<TrivialThing*>(malloc());
>   p->a = 0; // UB, no object of type TrivialThing here
>
> I'll reiterate what the paper says: there is no change to the status quo
> here; the standard previously said this was UB, and still does. Fixing this
> (if the committee agrees that it is a bug) should be done by a separate
> paper.

I'm seeing one more problem that the above code can be said to have
defined behavior based on 3.8 [basic.life] p1 (as discussed in SG12).

But yes, if the approval of this paper doesn't affect on that, it is a
separate issue. (#1116 <http://wg21.cmeerw.net/cwg/issue1116>, or new
one...)

>> Second one is that the paper seems banning casts between pointer to a
>> class and pointer to its first subobject. There seems to be some C
....
> This was the subject of some debate. The previous draft of the paper
> intended to allow such casts in the cases where the standard guaranteed the
> addresses are the same (indeed, that seemed to be the purpose of such
> guarantees). We backed off this when it was observed that an existing C++
> optimizer was already optimizing on the basis of such casts being invalid,
> based on a (reasonable) reading of the current wording of the standard.
>
> This probably warrants more debate by CWG. If possible, I'd like to
> guarantee that casting between a pointer-to-standard-layout-class and its
> first element gives a usable pointer value, and likewise for casting
> between a pointer to an array and its first element and for casting between
> a pointer to a union and any element type. This seems to be the intent of
> the current standard wording, even if a strict interpretation of the words
> could give another conclusion.

This is a news for me. Could you please point the relevant wording, and
hopefully an example with such optimizer (compiler and version, etc)?


>> Is it good to send CC to the e-mail address in paper to post about a
>> paper? (I think it is good, but I forgot to do that this time.)
>
> This author reads std-proposals :) But yes, as general advice, you should
> contact the author of the paper when providing feedback; that's why the
> papers contain an email address for the author.

OK. I'll do that next time.

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Sun, Jun 28, 2015 at 7:37 AM, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
wrote:

> On 2015/06/28 16:11, Richard Smith wrote:
> > Regarding 3.8/7: I don't see that any changes are required there. It
> > continues to be the case that replacing an object of a class with
> reference
> > or const members invalidates all pointers, references, and names that
> refer
> > to the original object, in the sense that they cannot be used to access
> the
> > new object. Accessing the new object starting from an old
> > pointer/reference/name requires use of std::launder.
>
> OK I got the idea of that. I should re-read the paper. Thank you.
>
> If possible, I want to see a newer version of the paper or list of
> feedbacks already given.


The committee's internal discussions on a paper are not public; this is
deliberate as it allows us to talk more freely about issues that (for
corporate, personal or legal reasons) we would not wish to disclose more
widely (and it allows us to express views and opinions without fear of
being publicly embarrassed when we inevitably make mistakes!).

I'm not sure exactly when I'll produce a newer version of the wording; I
expect there'll be at least one core drafting review teleconference between
now and Kona, and I should have revised wording for that review. I'll try
to remember to post the wording here in advance of that.

>> First concern with C incompatibility is that the paper says "malloc
> >> alone is not sufficient to create an object" as "the status quo". But
> ...
> > This paper does not change anything here. In C++, malloc has never
> created
> > an object because [intro.object]/1 says that an object is *only* created
> by
> > a new-expression, declaration, or when an implementation creates a
> > temporary object (malloc is none of these). I agree that this is a
> problem,
> > and it's very common to see programs do this:
> >
> >   struct TrivialThing { int a, b, c; };
> >   TrivialThing *p = reinterpret_cast<TrivialThing*>(malloc());
> >   p->a = 0; // UB, no object of type TrivialThing here
> >
> > I'll reiterate what the paper says: there is no change to the status quo
> > here; the standard previously said this was UB, and still does. Fixing
> this
> > (if the committee agrees that it is a bug) should be done by a separate
> > paper.
>
> I'm seeing one more problem that the above code can be said to have
> defined behavior based on 3.8 [basic.life] p1 (as discussed in SG12).
>
> But yes, if the approval of this paper doesn't affect on that, it is a
> separate issue. (#1116 <http://wg21.cmeerw.net/cwg/issue1116>, or new
> one...)
>
> >> Second one is that the paper seems banning casts between pointer to a
> >> class and pointer to its first subobject. There seems to be some C
> ...
> > This was the subject of some debate. The previous draft of the paper
> > intended to allow such casts in the cases where the standard guaranteed
> the
> > addresses are the same (indeed, that seemed to be the purpose of such
> > guarantees). We backed off this when it was observed that an existing C++
> > optimizer was already optimizing on the basis of such casts being
> invalid,
> > based on a (reasonable) reading of the current wording of the standard.
> >
> > This probably warrants more debate by CWG. If possible, I'd like to
> > guarantee that casting between a pointer-to-standard-layout-class and its
> > first element gives a usable pointer value, and likewise for casting
> > between a pointer to an array and its first element and for casting
> between
> > a pointer to a union and any element type. This seems to be the intent of
> > the current standard wording, even if a strict interpretation of the
> words
> > could give another conclusion.
>
> This is a news for me. Could you please point the relevant wording, and
> hopefully an example with such optimizer (compiler and version, etc)?


I'll check with the person from whom I received the information whether
it's OK to make that public.

>> Is it good to send CC to the e-mail address in paper to post about a
> >> paper? (I think it is good, but I forgot to do that this time.)
> >
> > This author reads std-proposals :) But yes, as general advice, you should
> > contact the author of the paper when providing feedback; that's why the
> > papers contain an email address for the author.
>
> OK. I'll do that next time.
>
> --
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--20cf30334c17e64b38051999a88c
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=
un, Jun 28, 2015 at 7:37 AM, Kazutoshi Satoda <span dir=3D"ltr">&lt;<a href=
=3D"mailto:k_satoda@f2.dion.ne.jp" target=3D"_blank">k_satoda@f2.dion.ne.jp=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">O=
n 2015/06/28 16:11, Richard Smith wrote:<br>
&gt; Regarding 3.8/7: I don&#39;t see that any changes are required there. =
It<br>
&gt; continues to be the case that replacing an object of a class with refe=
rence<br>
&gt; or const members invalidates all pointers, references, and names that =
refer<br>
&gt; to the original object, in the sense that they cannot be used to acces=
s the<br>
&gt; new object. Accessing the new object starting from an old<br>
&gt; pointer/reference/name requires use of std::launder.<br>
<br>
</span>OK I got the idea of that. I should re-read the paper. Thank you.<br=
>
<br>
If possible, I want to see a newer version of the paper or list of<br>
feedbacks already given.</blockquote><div><br></div><div>The committee&#39;=
s internal discussions on a paper are not public; this is deliberate as it =
allows us to talk more freely about issues that (for corporate, personal or=
 legal reasons) we would not wish to disclose more widely (and it allows us=
 to express views and opinions without fear of being publicly embarrassed w=
hen we inevitably make mistakes!).</div><div><br></div><div>I&#39;m not sur=
e exactly when I&#39;ll produce a newer version of the wording; I expect th=
ere&#39;ll be at least one core drafting review teleconference between now =
and Kona, and I should have revised wording for that review. I&#39;ll try t=
o remember to post the wording here in advance of that.</div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D"">
&gt;&gt; First concern with C incompatibility is that the paper says &quot;=
malloc<br>
&gt;&gt; alone is not sufficient to create an object&quot; as &quot;the sta=
tus quo&quot;. But<br>
</span>...<br>
<span class=3D"">&gt; This paper does not change anything here. In C++, mal=
loc has never created<br>
&gt; an object because [intro.object]/1 says that an object is *only* creat=
ed by<br>
&gt; a new-expression, declaration, or when an implementation creates a<br>
&gt; temporary object (malloc is none of these). I agree that this is a pro=
blem,<br>
&gt; and it&#39;s very common to see programs do this:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0struct TrivialThing { int a, b, c; };<br>
&gt;=C2=A0 =C2=A0TrivialThing *p =3D reinterpret_cast&lt;TrivialThing*&gt;(=
malloc());<br>
&gt;=C2=A0 =C2=A0p-&gt;a =3D 0; // UB, no object of type TrivialThing here<=
br>
&gt;<br>
&gt; I&#39;ll reiterate what the paper says: there is no change to the stat=
us quo<br>
&gt; here; the standard previously said this was UB, and still does. Fixing=
 this<br>
&gt; (if the committee agrees that it is a bug) should be done by a separat=
e<br>
&gt; paper.<br>
<br>
</span>I&#39;m seeing one more problem that the above code can be said to h=
ave<br>
defined behavior based on 3.8 [basic.life] p1 (as discussed in SG12).<br>
<br>
But yes, if the approval of this paper doesn&#39;t affect on that, it is a<=
br>
separate issue. (#1116 &lt;<a href=3D"http://wg21.cmeerw.net/cwg/issue1116"=
 rel=3D"noreferrer" target=3D"_blank">http://wg21.cmeerw.net/cwg/issue1116<=
/a>&gt;, or new<br>
one...)<br>
<span class=3D""><br>
&gt;&gt; Second one is that the paper seems banning casts between pointer t=
o a<br>
&gt;&gt; class and pointer to its first subobject. There seems to be some C=
<br>
</span>...<br>
<span class=3D"">&gt; This was the subject of some debate. The previous dra=
ft of the paper<br>
&gt; intended to allow such casts in the cases where the standard guarantee=
d the<br>
&gt; addresses are the same (indeed, that seemed to be the purpose of such<=
br>
&gt; guarantees). We backed off this when it was observed that an existing =
C++<br>
&gt; optimizer was already optimizing on the basis of such casts being inva=
lid,<br>
&gt; based on a (reasonable) reading of the current wording of the standard=
..<br>
&gt;<br>
&gt; This probably warrants more debate by CWG. If possible, I&#39;d like t=
o<br>
&gt; guarantee that casting between a pointer-to-standard-layout-class and =
its<br>
&gt; first element gives a usable pointer value, and likewise for casting<b=
r>
&gt; between a pointer to an array and its first element and for casting be=
tween<br>
&gt; a pointer to a union and any element type. This seems to be the intent=
 of<br>
&gt; the current standard wording, even if a strict interpretation of the w=
ords<br>
&gt; could give another conclusion.<br>
<br>
</span>This is a news for me. Could you please point the relevant wording, =
and<br>
hopefully an example with such optimizer (compiler and version, etc)?</bloc=
kquote><div><br></div><div>I&#39;ll check with the person from whom I recei=
ved the information whether it&#39;s OK to make that public.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D"">
&gt;&gt; Is it good to send CC to the e-mail address in paper to post about=
 a<br>
&gt;&gt; paper? (I think it is good, but I forgot to do that this time.)<br=
>
&gt;<br>
&gt; This author reads std-proposals :) But yes, as general advice, you sho=
uld<br>
&gt; contact the author of the paper when providing feedback; that&#39;s wh=
y the<br>
&gt; papers contain an email address for the author.<br>
<br>
</span>OK. I&#39;ll do that next time.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
k_satoda<br>
<br>
--<br>
<br>
---<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--20cf30334c17e64b38051999a88c--

.

------=_Part_1371_1445215387.1436469951970
Content-Type: multipart/alternative;
 boundary="----=_Part_1372_2100823843.1436469951970"

------=_Part_1372_2100823843.1436469951970
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, June 28, 2015 at 12:11:49 AM UTC-7, Richard Smith wrote:
>
> On Sat, Jun 27, 2015 at 8:52 PM, Kazutoshi Satoda <k_sa...@f2.dion.ne.jp=
=20
> <javascript:>> wrote:
>
>>
>> First concern with C incompatibility is that the paper says "malloc
>> alone is not sufficient to create an object" as "the status quo". But
>> in C, malloc (or other allocation functions) is the only way to create
>> objects with dynamic storage duration. If changes (proposed and
>> foreseen) based on that "status quo" are accepted, many C programs will
>> be seen invalid with C++ compiler and may be broken silently.
>>
>
> This paper does not change anything here. In C++, malloc has never create=
d=20
> an object because [intro.object]/1 says that an object is *only* created =
by=20
> a new-expression, declaration, or when an implementation creates a=20
> temporary object (malloc is none of these). I agree that this is a proble=
m,=20
> and it's very common to see programs do this:
>
>   struct TrivialThing { int a, b, c; };
>   TrivialThing *p =3D reinterpret_cast<TrivialThing*>(malloc());
>   p->a =3D 0; // UB, no object of type TrivialThing here
> =20
> I'll reiterate what the paper says: there is no change to the status quo=
=20
> here; the standard previously said this was UB, and still does. Fixing th=
is=20
> (if the committee agrees that it is a bug) should be done by a separate=
=20
> paper.
>
>
Why is that undefined behavior in the current Standard?  [basic.life]/1:

The *lifetime* of an object is a runtime property of the object.  An object=
=20
> is said to have *non-vacuous initialization* if it is of a class or=20
> aggregate type and it or one of its members is initialized by a construct=
or=20
> other than a trivial default constructor.  [*Note:* initialization by a=
=20
> trivial copy/move constructor is non-vacuous initialization. *=E2=80=94 e=
nd note*] =20
> The lifetime of an object of type T begins when:
>
> =E2=80=94 storage with the proper alignment and size for type T is obtain=
ed; and
> =E2=80=94 if the object has non-vacuous initialization, its initializatio=
n is=20
> complete.
>
>
TrivialThing has vacuous initialization.  malloc(sizeof(TrivialThing))=20
allocates storage of the proper size.  Only alignment remains as a concern,=
=20
but without an alignas attribute, it isn't possible for a standard-layout=
=20
structure to require an alignment greater than that guaranteed by malloc()'=
s=20
definition.

If the argument is then about it not being "an object" until a new=20
expression, that interpretation leads to a contradiction: how can the=20
Standard talk about an object before its existence?  It'd imply a=20
contradiction in the Standard.


Looking at this, this proposal looks extremely bad for the future of C++,=
=20
unless the intent is to fork C++ into a new managed language.  The ability=
=20
to do some of the pointer manipulation banned by the proposal is relied=20
upon by way too much code.  In fact, C++ programmers are used to using=20
these mechanisms to get work done, because it's sometimes the best tool for=
=20
the job.

The above is extremely broken in particular: it means that many C libraries=
=20
with such statements in macros or inline functions in header files can't be=
=20
used in C++ programs anymore.  If you try to use one of these C functions,=
=20
the compiler will just willy-nilly delete your code from existence without=
=20
warning.

Then there is the matter of pool allocators: with such strict rules on=20
pointer manipulation, it's impossible to write a meaningful pool allocator=
=20
or similar construction.  Unless you want to write such things in C since=
=20
C++ would be too strict to allow it.

Optimization is not the only goal =E2=80=94 usability, versatility, intelli=
gibility=20
and self-consistency are also goals.

> struct derived d;
>> > struct base *base_ptr =3D (struct base *)&d;  // upcast
>> > struct derived *derived_ptr =3D (struct derived *)base_ptr;  // downca=
st
>>
>> I think these are valid C program, and C++ also allow them with some
>> special rules to keep compatibility with C. The paper seems like
>> removing one of them.
>>
>
> This was the subject of some debate. The previous draft of the paper=20
> intended to allow such casts in the cases where the standard guaranteed t=
he=20
> addresses are the same (indeed, that seemed to be the purpose of such=20
> guarantees). We backed off this when it was observed that an existing C++=
=20
> optimizer was already optimizing on the basis of such casts being invalid=
,=20
> based on a (reasonable) reading of the current wording of the standard.
>
> This probably warrants more debate by CWG. If possible, I'd like to=20
> guarantee that casting between a pointer-to-standard-layout-class and its=
=20
> first element gives a usable pointer value, and likewise for casting=20
> between a pointer to an array and its first element and for casting betwe=
en=20
> a pointer to a union and any element type. This seems to be the intent of=
=20
> the current standard wording, even if a strict interpretation of the word=
s=20
> could give another conclusion.
> =20
>
>
Without support for this, struct sockaddr does not work.

Melissa

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

On Sunday, June 28, 2015 at 12:11:49 AM UTC-7, Richard Smith wrote:<blockqu=
ote 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 class=3D"gm=
ail_quote">On Sat, Jun 27, 2015 at 8:52 PM, Kazutoshi Satoda <span dir=3D"l=
tr">&lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">k_sa...@f2.dion.ne.jp</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">

<br>
First concern with C incompatibility is that the paper says &quot;malloc<br=
>
alone is not sufficient to create an object&quot; as &quot;the status quo&q=
uot;. But<br>
in C, malloc (or other allocation functions) is the only way to create<br>
objects with dynamic storage duration. If changes (proposed and<br>
foreseen) based on that &quot;status quo&quot; are accepted, many C program=
s will<br>
be seen invalid with C++ compiler and may be broken silently.<br></blockquo=
te><div><br></div><div>This paper does not change anything here. In C++, ma=
lloc has never created an object because [intro.object]/1 says that an obje=
ct is *only* created by a new-expression, declaration, or when an implement=
ation creates a temporary object (malloc is none of these). I agree that th=
is is a problem, and it&#39;s very common to see programs do this:</div><di=
v><br></div><div>=C2=A0 struct TrivialThing { int a, b, c; };</div><div>=C2=
=A0 TrivialThing *p =3D reinterpret_cast&lt;TrivialThing*&gt;(malloc());</d=
iv><div>=C2=A0 p-&gt;a =3D 0; // UB, no object of type TrivialThing here</d=
iv><div>=C2=A0</div><div>I&#39;ll reiterate what the paper says: there is n=
o change to the status quo here; the standard previously said this was UB, =
and still does. Fixing this (if the committee agrees that it is a bug) shou=
ld be done by a separate paper.</div><div><br></div></div></div></div></blo=
ckquote><div><br>Why is that undefined behavior in the current Standard?=C2=
=A0 [basic.life]/1:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gma=
il_quote">The <i>lifetime</i> of an object is a runtime property of the obj=
ect.=C2=A0 An object is said to have <i>non-vacuous initialization</i> if i=
t is of a class or aggregate type and it or one of its members is initializ=
ed by a constructor other than a trivial default constructor.=C2=A0 [<i>Not=
e:</i> initialization by a trivial copy/move constructor is non-vacuous ini=
tialization. <i>=E2=80=94 end note</i>]=C2=A0 The lifetime of an object of =
type <span style=3D"font-family: courier new,monospace;">T</span> begins wh=
en:<br><br>=E2=80=94 storage with the proper alignment and size for type <s=
pan style=3D"font-family: courier new,monospace;">T</span> is obtained; and=
<br>=E2=80=94 if the object has non-vacuous initialization, its initializat=
ion is complete.<br><br></blockquote><br><span style=3D"font-family: courie=
r new,monospace;">TrivialThing</span> has vacuous initialization.=C2=A0 <sp=
an style=3D"font-family: courier new,monospace;">malloc(sizeof(TrivialThing=
))</span> allocates storage of the proper size.=C2=A0 Only alignment remain=
s as a concern, but without an <span style=3D"font-family: courier new,mono=
space;">alignas</span> attribute, it isn&#39;t possible for a standard-layo=
ut structure to require an alignment greater than that guaranteed by <span =
style=3D"font-family: courier new,monospace;">malloc()</span>&#39;s definit=
ion.<br><br>If the argument is then about it not being &quot;an object&quot=
; until a <span style=3D"font-family: courier new,monospace;">new</span> ex=
pression, that interpretation leads to a contradiction: how can the Standar=
d talk about an object before its existence?=C2=A0 It&#39;d imply a contrad=
iction in the Standard.<br><br><br>Looking at this, this proposal looks ext=
remely bad for the future of
 C++, unless the intent is to fork C++ into a new managed language.=C2=A0 T=
he=20
ability to do some of the pointer manipulation banned by the proposal is
 relied upon by way too much code.=C2=A0 In fact, C++ programmers are used =
to using these mechanisms to get work done, because it&#39;s sometimes the =
best tool for the job.<br><br>The above is extremely broken in particular: =
it means that many C libraries with such statements in macros or inline fun=
ctions in header files can&#39;t be used in C++ programs anymore.=C2=A0 If =
you try to use one of these C functions, the compiler will just willy-nilly=
 delete your code from existence without warning.<br><br>Then there is the =
matter of pool allocators: with such strict rules on pointer manipulation, =
it&#39;s impossible to write a meaningful pool allocator or similar constru=
ction.=C2=A0 Unless you want to write such things in C since C++ would be t=
oo strict to allow it.<br><br>Optimization is not the only goal =E2=80=94 u=
sability, versatility, intelligibility and self-consistency are also goals.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; struct derived d;<br>
&gt; struct base *base_ptr =3D (struct base *)&amp;d;=C2=A0 // upcast<br>
&gt; struct derived *derived_ptr =3D (struct derived *)base_ptr;=C2=A0 // d=
owncast<br>
<br>
I think these are valid C program, and C++ also allow them with some<br>
special rules to keep compatibility with C. The paper seems like<br>
removing one of them.<br></blockquote><div><br></div><div>This was the subj=
ect of some debate. The previous draft of the paper intended to allow such =
casts in the cases where the standard guaranteed the addresses are the same=
 (indeed, that seemed to be the purpose of such guarantees). We backed off =
this when it was observed that an existing C++ optimizer was already optimi=
zing on the basis of such casts being invalid, based on a (reasonable) read=
ing of the current wording of the standard.</div><div><br></div><div>This p=
robably warrants more debate by CWG. If possible, I&#39;d like to guarantee=
 that casting between a pointer-to-standard-layout-class and its first elem=
ent gives a usable pointer value, and likewise for casting between a pointe=
r to an array and its first element and for casting between a pointer to a =
union and any element type. This seems to be the intent of the current stan=
dard wording, even if a strict interpretation of the words could give anoth=
er conclusion.</div><div>=C2=A0</div><br></div></div></div></blockquote><di=
v><br>Without support for this, <span style=3D"font-family: courier new,mon=
ospace;">struct sockaddr</span> does not work.<br><br>Melissa<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1372_2100823843.1436469951970--
------=_Part_1371_1445215387.1436469951970--

.

--bcaec5489e451d3a60051a7776bf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 9, 2015 at 12:25 PM, Myriachan <myriachan@gmail.com> wrote:

> On Sunday, June 28, 2015 at 12:11:49 AM UTC-7, Richard Smith wrote:
>>
>> On Sat, Jun 27, 2015 at 8:52 PM, Kazutoshi Satoda <k_sa...@f2.dion.ne.jp=
>
>> wrote:
>>
>>>
>>> First concern with C incompatibility is that the paper says "malloc
>>> alone is not sufficient to create an object" as "the status quo". But
>>> in C, malloc (or other allocation functions) is the only way to create
>>> objects with dynamic storage duration. If changes (proposed and
>>> foreseen) based on that "status quo" are accepted, many C programs will
>>> be seen invalid with C++ compiler and may be broken silently.
>>>
>>
>> This paper does not change anything here. In C++, malloc has never
>> created an object because [intro.object]/1 says that an object is *only*
>> created by a new-expression, declaration, or when an implementation crea=
tes
>> a temporary object (malloc is none of these). I agree that this is a
>> problem, and it's very common to see programs do this:
>>
>>   struct TrivialThing { int a, b, c; };
>>   TrivialThing *p =3D reinterpret_cast<TrivialThing*>(malloc());
>>   p->a =3D 0; // UB, no object of type TrivialThing here
>>
>> I'll reiterate what the paper says: there is no change to the status quo
>> here; the standard previously said this was UB, and still does. Fixing t=
his
>> (if the committee agrees that it is a bug) should be done by a separate
>> paper.
>>
>>
> Why is that undefined behavior in the current Standard?  [basic.life]/1:
>
> The *lifetime* of an object is a runtime property of the object.  An
>> object is said to have *non-vacuous initialization* if it is of a class
>> or aggregate type and it or one of its members is initialized by a
>> constructor other than a trivial default constructor.  [*Note:*
>> initialization by a trivial copy/move constructor is non-vacuous
>> initialization. *=E2=80=94 end note*]  The lifetime of an object of type=
 T
>> begins when:
>>
>> =E2=80=94 storage with the proper alignment and size for type T is obtai=
ned; and
>> =E2=80=94 if the object has non-vacuous initialization, its initializati=
on is
>> complete.
>>
>>
> TrivialThing has vacuous initialization.
>

"Vacuous initialization" is a property of an object, not a type, per the
text you quoted. The above code does not create an object of type
TrivialType.

malloc(sizeof(TrivialThing)) allocates storage of the proper size.  Only
> alignment remains as a concern, but without an alignas attribute, it
> isn't possible for a standard-layout structure to require an alignment
> greater than that guaranteed by malloc()'s definition.
>
> If the argument is then about it not being "an object" until a new
> expression, that interpretation leads to a contradiction: how can the
> Standard talk about an object before its existence?  It'd imply a
> contradiction in the Standard.
>

There's only a contradiction if you ignore [basic.life]/1 and imagine that
an object is created in the above case. To reiterate what I said before: I
too think this is a problem, but it's a pre-existing problem.

Looking at this, this proposal looks extremely bad for the future of C++,
> unless the intent is to fork C++ into a new managed language.
>

I think you are mistaken about the effect of the change. C++ has always had
stronger semantic rules than many people imagined; there are a lot of
constructs that implementations intentionally permit despite them not
having defined behavior (and more that are permitted simply because that is
the current emergent behavior of the implementations in question). Some of
these rules should probably be weakened, but that is orthogonal to this
proposal.

Fundamentally, I think you're right to complain, but your complaint is
misdirected: you shouldn't be against this proposal simply because it has
brought a pre-existing problem to your attention. The right thing to do
here is to work out what the rules should be, and to work towards allowing
the reasonable constructs that people currently assume should work but the
standard disallows (following the example of n3751).

The ability to do some of the pointer manipulation banned by the proposal
> is relied upon by way too much code.  In fact, C++ programmers are used t=
o
> using these mechanisms to get work done, because it's sometimes the best
> tool for the job.
>
> The above is extremely broken in particular: it means that many C
> libraries with such statements in macros or inline functions in header
> files can't be used in C++ programs anymore.  If you try to use one of
> these C functions, the compiler will just willy-nilly delete your code fr=
om
> existence without warning.
>
> Then there is the matter of pool allocators: with such strict rules on
> pointer manipulation, it's impossible to write a meaningful pool allocato=
r
> or similar construction.  Unless you want to write such things in C since
> C++ would be too strict to allow it.
>
> Optimization is not the only goal =E2=80=94 usability, versatility,
> intelligibility and self-consistency are also goals.
>
> > struct derived d;
>>> > struct base *base_ptr =3D (struct base *)&d;  // upcast
>>> > struct derived *derived_ptr =3D (struct derived *)base_ptr;  // downc=
ast
>>>
>>> I think these are valid C program, and C++ also allow them with some
>>> special rules to keep compatibility with C. The paper seems like
>>> removing one of them.
>>>
>>
>> This was the subject of some debate. The previous draft of the paper
>> intended to allow such casts in the cases where the standard guaranteed =
the
>> addresses are the same (indeed, that seemed to be the purpose of such
>> guarantees). We backed off this when it was observed that an existing C+=
+
>> optimizer was already optimizing on the basis of such casts being invali=
d,
>> based on a (reasonable) reading of the current wording of the standard.
>>
>> This probably warrants more debate by CWG. If possible, I'd like to
>> guarantee that casting between a pointer-to-standard-layout-class and it=
s
>> first element gives a usable pointer value, and likewise for casting
>> between a pointer to an array and its first element and for casting betw=
een
>> a pointer to a union and any element type. This seems to be the intent o=
f
>> the current standard wording, even if a strict interpretation of the wor=
ds
>> could give another conclusion.
>>
>>
>>
> Without support for this, struct sockaddr does not work.
>
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--bcaec5489e451d3a60051a7776bf
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, Jul 9, 2015 at 12:25 PM, Myriachan <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">On Sunday, June 28, 2015 at 12:11:49 AM UTC-7=
, Richard Smith wrote:<span class=3D""><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote">On Sat, Jun 27, 2015 at 8:52 PM, Kazutoshi Sa=
toda <span dir=3D"ltr">&lt;<a rel=3D"nofollow">k_sa...@f2.dion.ne.jp</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">

<br>
First concern with C incompatibility is that the paper says &quot;malloc<br=
>
alone is not sufficient to create an object&quot; as &quot;the status quo&q=
uot;. But<br>
in C, malloc (or other allocation functions) is the only way to create<br>
objects with dynamic storage duration. If changes (proposed and<br>
foreseen) based on that &quot;status quo&quot; are accepted, many C program=
s will<br>
be seen invalid with C++ compiler and may be broken silently.<br></blockquo=
te><div><br></div><div>This paper does not change anything here. In C++, ma=
lloc has never created an object because [intro.object]/1 says that an obje=
ct is *only* created by a new-expression, declaration, or when an implement=
ation creates a temporary object (malloc is none of these). I agree that th=
is is a problem, and it&#39;s very common to see programs do this:</div><di=
v><br></div><div>=C2=A0 struct TrivialThing { int a, b, c; };</div><div>=C2=
=A0 TrivialThing *p =3D reinterpret_cast&lt;TrivialThing*&gt;(malloc());</d=
iv><div>=C2=A0 p-&gt;a =3D 0; // UB, no object of type TrivialThing here</d=
iv><div>=C2=A0</div><div>I&#39;ll reiterate what the paper says: there is n=
o change to the status quo here; the standard previously said this was UB, =
and still does. Fixing this (if the committee agrees that it is a bug) shou=
ld be done by a separate paper.</div><div><br></div></div></div></div></blo=
ckquote></span><div><br>Why is that undefined behavior in the current Stand=
ard?=C2=A0 [basic.life]/1:<br><br><blockquote style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex" class=3D"gmail_quote">The <i>lifetime</i> of a=
n object is a runtime property of the object.=C2=A0 An object is said to ha=
ve <i>non-vacuous initialization</i> if it is of a class or aggregate type =
and it or one of its members is initialized by a constructor other than a t=
rivial default constructor.=C2=A0 [<i>Note:</i> initialization by a trivial=
 copy/move constructor is non-vacuous initialization. <i>=E2=80=94 end note=
</i>]=C2=A0 The lifetime of an object of type <span style=3D"font-family:&#=
39;courier new&#39;,monospace">T</span> begins when:<br><br>=E2=80=94 stora=
ge with the proper alignment and size for type <span style=3D"font-family:&=
#39;courier new&#39;,monospace">T</span> is obtained; and<br>=E2=80=94 if t=
he object has non-vacuous initialization, its initialization is complete.<b=
r><br></blockquote><br><span style=3D"font-family:&#39;courier new&#39;,mon=
ospace">TrivialThing</span> has vacuous initialization.</div></blockquote><=
div><br></div><div>&quot;Vacuous initialization&quot; is a property of an o=
bject, not a type, per the text you quoted. The above code does not create =
an object of type TrivialType.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><s=
pan style=3D"font-family:&#39;courier new&#39;,monospace">malloc(sizeof(Tri=
vialThing))</span> allocates storage of the proper size.=C2=A0 Only alignme=
nt remains as a concern, but without an <span style=3D"font-family:&#39;cou=
rier new&#39;,monospace">alignas</span> attribute, it isn&#39;t possible fo=
r a standard-layout structure to require an alignment greater than that gua=
ranteed by <span style=3D"font-family:&#39;courier new&#39;,monospace">mall=
oc()</span>&#39;s definition.<br><br>If the argument is then about it not b=
eing &quot;an object&quot; until a <span style=3D"font-family:&#39;courier =
new&#39;,monospace">new</span> expression, that interpretation leads to a c=
ontradiction: how can the Standard talk about an object before its existenc=
e?=C2=A0 It&#39;d imply a contradiction in the Standard.<br></div></blockqu=
ote><div><br></div><div>There&#39;s only a contradiction if you ignore [bas=
ic.life]/1 and imagine that an object is created in the above case. To reit=
erate what I said before: I too think this is a problem, but it&#39;s a pre=
-existing problem.</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div>Looking at thi=
s, this proposal looks extremely bad for the future of
 C++, unless the intent is to fork C++ into a new managed language.</div></=
blockquote><div><br></div><div>I think you are mistaken about the effect of=
 the change. C++ has always had stronger semantic rules than many people im=
agined; there are a lot of constructs that implementations intentionally pe=
rmit despite them not having defined behavior (and more that are permitted =
simply because that is the current emergent behavior of the implementations=
 in question). Some of these rules should probably be weakened, but that is=
 orthogonal to this proposal.</div><div><br></div><div>Fundamentally, I thi=
nk you&#39;re right to complain, but your complaint is misdirected: you sho=
uldn&#39;t be against this proposal simply because it has brought a pre-exi=
sting problem to your attention. The right thing to do here is to work out =
what the rules should be, and to work towards allowing the reasonable const=
ructs that people currently assume should work but the standard disallows (=
following the example of n3751).</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>=
The=20
ability to do some of the pointer manipulation banned by the proposal is
 relied upon by way too much code.=C2=A0 In fact, C++ programmers are used =
to using these mechanisms to get work done, because it&#39;s sometimes the =
best tool for the job.<br><br>The above is extremely broken in particular: =
it means that many C libraries with such statements in macros or inline fun=
ctions in header files can&#39;t be used in C++ programs anymore.=C2=A0 If =
you try to use one of these C functions, the compiler will just willy-nilly=
 delete your code from existence without warning.<br><br>Then there is the =
matter of pool allocators: with such strict rules on pointer manipulation, =
it&#39;s impossible to write a meaningful pool allocator or similar constru=
ction.=C2=A0 Unless you want to write such things in C since C++ would be t=
oo strict to allow it.<br><br>Optimization is not the only goal =E2=80=94 u=
sability, versatility, intelligibility and self-consistency are also goals.=
<br><br></div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex">
&gt; struct derived d;<br>
&gt; struct base *base_ptr =3D (struct base *)&amp;d;=C2=A0 // upcast<br>
&gt; struct derived *derived_ptr =3D (struct derived *)base_ptr;=C2=A0 // d=
owncast<br>
<br>
I think these are valid C program, and C++ also allow them with some<br>
special rules to keep compatibility with C. The paper seems like<br>
removing one of them.<br></blockquote><div><br></div><div>This was the subj=
ect of some debate. The previous draft of the paper intended to allow such =
casts in the cases where the standard guaranteed the addresses are the same=
 (indeed, that seemed to be the purpose of such guarantees). We backed off =
this when it was observed that an existing C++ optimizer was already optimi=
zing on the basis of such casts being invalid, based on a (reasonable) read=
ing of the current wording of the standard.</div><div><br></div><div>This p=
robably warrants more debate by CWG. If possible, I&#39;d like to guarantee=
 that casting between a pointer-to-standard-layout-class and its first elem=
ent gives a usable pointer value, and likewise for casting between a pointe=
r to an array and its first element and for casting between a pointer to a =
union and any element type. This seems to be the intent of the current stan=
dard wording, even if a strict interpretation of the words could give anoth=
er conclusion.</div><div>=C2=A0</div><br></div></div></div></blockquote></s=
pan><div><br>Without support for this, <span style=3D"font-family:&#39;cour=
ier new&#39;,monospace">struct sockaddr</span> does not work.<br><br>Meliss=
a<br></div><div class=3D""><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec5489e451d3a60051a7776bf--

.

On 2015/06/29 5:17, Richard Smith wrote:
> The committee's internal discussions on a paper are not public; this is
> deliberate as it allows us to talk more freely about issues that (for
> corporate, personal or legal reasons) we would not wish to disclose more
> widely (and it allows us to express views and opinions without fear of
> being publicly embarrassed when we inevitably make mistakes!).

Fair enough. But I believe decisions from such discussions and their
rationales will be recored in public papers.

The current version (N4430) seems too quiet on that. I expect revised
one will include answers to given questions and possibly some more which
were already solved by yourself or in the committee.

>>>> Second one is that the paper seems banning casts between pointer to a
>>>> class and pointer to its first subobject. There seems to be some C
....
>>> guarantees). We backed off this when it was observed that an existing C++
>>> optimizer was already optimizing on the basis of such casts being invalid,
>>> based on a (reasonable) reading of the current wording of the standard.
....
>> This is a news for me. Could you please point the relevant wording, and
>> hopefully an example with such optimizer (compiler and version, etc)?
>
> I'll check with the person from whom I received the information whether
> it's OK to make that public.

Could you please just point the relevant wording in the standard?

I understand compiler information would be non-public, but wordings in
the standard should not be a problem.

I suspect that wording could be a defect and better to fix, meaning to
ban the above mentioned relatively unknown optimization, instead of
banning already wide spread use of the casts.


I also wonder if it is possible or not to plug the effect of
std::launder() to some use of built-in cast operators and union member
access which are expected to be already written in lifetime
manipulations like optional<> do. That will reduce some chance of
optimization, but sounds safer direction and encouraging people to avoid
such cast for efficiency.

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Ping?

On 2015/07/11 16:44, Kazutoshi Satoda wrote:
....
> On 2015/06/29 5:17, Richard Smith wrote:
....
>>>>> Second one is that the paper seems banning casts between pointer to a
>>>>> class and pointer to its first subobject. There seems to be some C
> ...
>>>> guarantees). We backed off this when it was observed that an existing C++
>>>> optimizer was already optimizing on the basis of such casts being invalid,
>>>> based on a (reasonable) reading of the current wording of the standard.
> ...
>>> This is a news for me. Could you please point the relevant wording, and
>>> hopefully an example with such optimizer (compiler and version, etc)?
>>
>> I'll check with the person from whom I received the information whether
>> it's OK to make that public.
>
> Could you please just point the relevant wording in the standard?
>
> I understand compiler information would be non-public, but wordings in
> the standard should not be a problem.
>
> I suspect that wording could be a defect and better to fix, meaning to
> ban the above mentioned relatively unknown optimization, instead of
> banning already wide spread use of the casts.
>
>
> I also wonder if it is possible or not to plug the effect of
> std::launder() to some use of built-in cast operators and union member
> access which are expected to be already written in lifetime
> manipulations like optional<> do. That will reduce some chance of
> optimization, but sounds safer direction and encouraging people to avoid
> such cast for efficiency.

One more question: Where std::launder() is expected to be written?
Is it written in library function (operator* of optional, operator[] of
vector, ...) or user code which use such functions with concerned types?

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.