On Mon, Jan 12, 2026 at 7:18 AM Thiago Macieira <thiago_at_[hidden]> wrote:
>
> 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.

How can another process actually *know* that this can happen? Are we
to presume that every time you create shared memory, that this also
creates some kind of interprocess communication interface outside of
that?

> > 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.

Or we could just clearly declare what's actually going on rather than
presuming systems can figure it out.