Date: Tue, 27 Dec 2022 16:05:19 -0500
Hi Matthew, I think it's worth submitting a core issue, so the Core Working
Group can discuss whether there's a defect in which the rule is too strict.
You can do so here: https://github.com/cplusplus/CWG/issues
The missing definition for "obtained, directly or indirectly, from the
constructor's `this` pointer" should also be reported as a separate core
issue.
On Mon, Dec 26, 2022 at 11:22 AM Matthew House via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> On Mon, Dec 26, 2022 at 7:05 AM Thiago Macieira via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
> > FYI, Arthur filed a bug against GCC at
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
>
> Ah, then perhaps my concern isn't so independent after all: reading
> that bug (and the linked bugs) is what prompted me to take a closer
> look at [basic.life] and [class.cdtor] in the first place.
>
> > The original question in #standardese was this source code:
> >
> > struct A {
> > virtual void f();
> > };
> >
> > struct B : virtual A {};
> >
> > struct C : virtual A {
> > C(B* p) {
> > A* q = p; // <---
> > }
> > };
> >
> > struct D : B, C {
> > D(): C(this) {}
> > };
> >
> > Which when compiled with GCC does produce a nonsensical pointer
> > (it's just over 4 MB away from where it should be, on testing).
> > Clang seems to be similarly affected, but only if the bases aren't
> > empty).
> >
> > And yet everyone who looks at this code says that it looks correct
> > and valid.
>
> For what it's worth, that code is also correct and valid by my own
> reading. Converting this from D* to B* is valid since there are no
> other bases between the two types (11.9.5 [class.cdtor] para. 3), and
> converting p from B* to A* is valid because the B subobject is within
> its lifetime. Perhaps the compilers (and/or the ABIs) are having
> trouble with the Standard's implication that each and every base class
> subobject, including each virtual base class subobject, must be fully
> valid and usable immediately after its constructor returns.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
Group can discuss whether there's a defect in which the rule is too strict.
You can do so here: https://github.com/cplusplus/CWG/issues
The missing definition for "obtained, directly or indirectly, from the
constructor's `this` pointer" should also be reported as a separate core
issue.
On Mon, Dec 26, 2022 at 11:22 AM Matthew House via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> On Mon, Dec 26, 2022 at 7:05 AM Thiago Macieira via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
> > FYI, Arthur filed a bug against GCC at
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
>
> Ah, then perhaps my concern isn't so independent after all: reading
> that bug (and the linked bugs) is what prompted me to take a closer
> look at [basic.life] and [class.cdtor] in the first place.
>
> > The original question in #standardese was this source code:
> >
> > struct A {
> > virtual void f();
> > };
> >
> > struct B : virtual A {};
> >
> > struct C : virtual A {
> > C(B* p) {
> > A* q = p; // <---
> > }
> > };
> >
> > struct D : B, C {
> > D(): C(this) {}
> > };
> >
> > Which when compiled with GCC does produce a nonsensical pointer
> > (it's just over 4 MB away from where it should be, on testing).
> > Clang seems to be similarly affected, but only if the bases aren't
> > empty).
> >
> > And yet everyone who looks at this code says that it looks correct
> > and valid.
>
> For what it's worth, that code is also correct and valid by my own
> reading. Converting this from D* to B* is valid since there are no
> other bases between the two types (11.9.5 [class.cdtor] para. 3), and
> converting p from B* to A* is valid because the B subobject is within
> its lifetime. Perhaps the compilers (and/or the ABIs) are having
> trouble with the Standard's implication that each and every base class
> subobject, including each virtual base class subobject, must be fully
> valid and usable immediately after its constructor returns.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
-- *Brian Bi*
Received on 2022-12-27 21:05:32