On 20/10/2022 07:11, Eric Schmidt via Std-Discussion wrote:
> This issue came up on a StackOverflow question:
>
> https://stackoverflow.com/questions/74080177/double-free-in-the-c-standard-library-using-only-stdfunction-and-stdshared/74080676
>
> This led to a discussion here:
>
> https://chat.stackoverflow.com/rooms/248862/discuss-lwg2224
>
> Now, https://eel.is/c++draft/res.on.objects states
>
> "If an object of a standard library type is accessed, and the beginning of the object's lifetime does not happen before the access, or the access does not happen before the end of the object's lifetime, the behavior is undefined unless otherwise specified."
>
> According to a non-normative note in https://eel.is/c++draft/defns.access,
>
> "Only glvalues of scalar type can be used to access objects. ... Attempts to read or modify an object of class type typically invoke a constructor or assignment operator; such invocations do not themselves constitute accesses, although they may involve accesses of scalar subobjects."
>
> The question is, can objects of class type be accessed?

Can, in some sense. But it would be UB. E.g.

struct S
{
 char buf[sizeof(int)];
} s;

reinterpret_cast<int&>(s) = 0; // kinda accesses `s`, but this violates strict aliasing, so the behavior is actually undefined

> Is it the intent that an access to a scalar subobject also constitutes an access to the object itself?

No

> If not, then it is impossible for objects of most library types to be accessed.

There are other things which are undefined if an object (or rather a pointer/glvalue referring to it) is used before the lifetime has started
https://timsong-cpp.github.io/cppwp/n4868/basic.life#6.sentence-5
https://timsong-cpp.github.io/cppwp/n4868/basic.life#7.sentence-4

> If so, then objects of many library types are unavoidably accessed by their own destructor, after the end of their lifetime. Either way, [res.on.objects] doesn't work.

Treat [res.on.objects] as a non-normative reminder about above-mentioned parts from [basic.life]
(But in general, there are lots of nonsensical wording in the library part, if read it from strict core part POV.)

> For reference, here is some previous discussion from 2014:
>
> https://groups.google.com/a/isocpp.org/g/std-discussion/c/BGsVyc0Ittw/m/atiDfIqnc-YJ
>
> And the LWG issue that led to the current wording:
>
> https://cplusplus.github.io/LWG/issue2224