On Tuesday, 11 November 2025 23:45:28 Pacific Standard Time Oliver Hunt via
Std-Proposals wrote:
> I’m not sure what you mean here? You could relocate from one location to a
> potentially overlapping destination, and the semantics as specified
> maintained the dynamic type. E.g the functional behaviour - absent
> technologies like pointer authentication - was identical to memmove, this
> included the hazard of performing a relocation where the static type did
> not match the dynamic type, which could result in object slicing, and a
> host of problems the follow from that.

That might be dangerous by itself. Today, containers must allocate+move+free,
which means the destination's dynamic type is always chosen by the container
itself, causing object slicing. There's no such thing as moving with a
retained dynamic type. Suddenly, if the container becomes capable of
relocation, it might relocate without slicing.

However, I do not recognise this as a valid use-case. Different container
implementations will grow at different thresholds, and memory allocators will
cause reallocations at different thresholds. Any code that attempts to retain a
different dynamic type is *already* broken, in spite of however many safety
hacks the developer may have used (e.g., reserve()).

> To my knowledge this was the intended behavior, as all arguments assumed
> that the behavior of TR without pointer auth was equivalent to memmove, but
> if it is expected to override the dynamic type of an object with the static
> type, then it is not longer memmove on _any_ implementation.

I don't think it was expected to override.

It simply declared that it is UB to relocate a type whose dynamic type does
not match the relocation operation. The fact that this is just a memmove() is
irrelevant.

> I presumed
> that this worked on the assumption that a developer had guaranteed that
> when relocating with static type A, an object with dynamic type B is the
> same size and ABI as the super type A, which is certainly a thing that
> people do. If the intent in this scenario is to mimic a copy constructor
> and revert the dynamic type to the relocated static type, then TR requires
> similar logic to replace the dynamic type across all platforms, not just
> those with ptrauth, i.e. it would not be memmove anywhere.

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