Date: Sun, 25 Dec 2022 19:28:09 -0300
On Sunday, 25 December 2022 14:33:36 -03 Matthew House via Std-Discussion
wrote:
> > I add that this is something UB could do, but not unspecified.
>
> What do you mean? The wording says that the value is unspecified, not
> that the behavior is undefined. At worst, the program could have
> implementation-defined behavior from reading an invalid pointer value.
I meant that values can't suddenly become unspecified after being specified,
short of memory deallocation and other end-of-lifetime operations, which
aren't the case here. Therefore, if this code was meant to be invalid, then it
can't be simply "unspecified", it has to go all the way to UB.
> This paragraph has been around for a long time, and to me it appears
> not to have been properly updated to account for virtual base classes.
> In ISO C++98 (12.1 [class.ctor] para. 15), it applied only to const
> objects under construction. In ISO C++17, it was expanded to apply to
> all objects under construction, in response to DR 2271. Based on the
> examples, the rationale appears to be to prevent programs from
> referring to the object under construction from external sources such
> as global variables. However, its wording is broad enough to also
> prevent a constructor from accessing a pointer into a virtual base
> class subobject, if that pointer was otherwise validly obtained from
> the constructor of a derived class.
Agreed.
Though another reading could say that your program is fully specified because
the variables are obtained from the constructor's this pointer in all its
bases and incarnations. It doesn't stop being valid or specified just because
it's crossed into another base. That would mean the issue we've been
discussing on cpplang is either a plain compiler bug or has a different source.
I still think some firmer language here would be welcome. For example, it
should be clear if the compilers are allowed to assume pointers passed into
the constructor can alias the object's storage or not, and in particular
whether this applies to virtual base sub-objects and the not-in-charge
constructors.
wrote:
> > I add that this is something UB could do, but not unspecified.
>
> What do you mean? The wording says that the value is unspecified, not
> that the behavior is undefined. At worst, the program could have
> implementation-defined behavior from reading an invalid pointer value.
I meant that values can't suddenly become unspecified after being specified,
short of memory deallocation and other end-of-lifetime operations, which
aren't the case here. Therefore, if this code was meant to be invalid, then it
can't be simply "unspecified", it has to go all the way to UB.
> This paragraph has been around for a long time, and to me it appears
> not to have been properly updated to account for virtual base classes.
> In ISO C++98 (12.1 [class.ctor] para. 15), it applied only to const
> objects under construction. In ISO C++17, it was expanded to apply to
> all objects under construction, in response to DR 2271. Based on the
> examples, the rationale appears to be to prevent programs from
> referring to the object under construction from external sources such
> as global variables. However, its wording is broad enough to also
> prevent a constructor from accessing a pointer into a virtual base
> class subobject, if that pointer was otherwise validly obtained from
> the constructor of a derived class.
Agreed.
Though another reading could say that your program is fully specified because
the variables are obtained from the constructor's this pointer in all its
bases and incarnations. It doesn't stop being valid or specified just because
it's crossed into another base. That would mean the issue we've been
discussing on cpplang is either a plain compiler bug or has a different source.
I still think some firmer language here would be welcome. For example, it
should be clear if the compilers are allowed to assume pointers passed into
the constructor can alias the object's storage or not, and in particular
whether this applies to virtual base sub-objects and the not-in-charge
constructors.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2022-12-25 22:28:35