On Sunday, 11 January 2026 16:46:59 Central Standard Time Jason McKesson via
Std-Proposals wrote:
> > I disagree. If I get a void pointer to a shared memory area and
> > static_cast it to my type, it should be ok. As far as I can tell, it's no
> > different than getting a pointer to an object whose lifetime was started
> > by another thread in this program. If the latter is enough to the
> > compiler, the former should too.
> How could the system possibly *know* that it's OK? How is it supposed
> to know the difference between a "shared memory area" and "something
> that looks like a shared memory area but isn't shared with anybody"?

There is no difference. If it is MAP_SHARED, it's shared memory, whether it's
being actively shared or not.

> How could the system possibly know if something else actually started
> the lifetime using the type you cast it to?

The program flow does.

The first process to create that memory area (the one that ftruncate'd the file
to extend its size from zero) must do std::construct_at to start the lifetime
of each and every object. All other processes that attach to it will share
this lifetime that has started.

> The difference with threading is that it's actually possible for that
> information to exist. Everything is in the same process, so there's a
> direct means of communicating that information from one area to
> another (ie: using memory).

It exists in the same way. In regular applications, that's nowhere, so it
doesn't matter.

If it were *really* required by the implementation, then shared memory would
need to map the information lifetime shared memory blocks too, the same way
that if something were to share *pointers*, it needs to map the colour map
too. Or whatever ARM64e needs for pointer authentication.

For UBSan, I don't care. UBSan is a tool to catch UB, not C++. It can be fixed.
And if it fails to catch some cases of shared memory, so be it. No one said
UBSan was perfect.


> You're basically asking for it to just not care, for it to just assume
> with no chance of verification or confirmation that whatever you're
> doing in these arbitrary circumstances is fine.

No. I am saying that the tools (UBsan) need to be adjusted to reality, not
that we should bend ourselves over backwards and change current, working
practice.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.