On 2021-06-23 at 08:35, language.lawyer--- via Std-Discussion wrote:
> On 29/04/2021 17:08, Jason Cobb via Std-Discussion wrote:
>> On 4/29/21 9:56 AM, Jason McKesson via Std-Discussion wrote:
>>> On Thu, Apr 29, 2021 at 4:31 AM Giuseppe D'Angelo via Std-Discussion
>>> <std-discussion_at_[hidden]> wrote:
>>>> Hello,
>>>>
>>>> On 29/04/2021 07:33, Christopher Hallock via Std-Discussion wrote:
>>>>> I was adding my own concerns about these library clauses being
>>>>> underspecified and overly broad. Getting back to your original
>>>>> question,
>>>>> which is whether library invalidation "sticks", given
>>>>> [basic.life]/8: I
>>>>> believe it does. If the invalidating operation move-assigns or
>>>>> copy-assigns the elements, then [basic.life]/8 doesn't even apply
>>>>> because no new object was created. If the invalidating operation
>>>>> move-constructs or copy-constructs the elements, then there is room
>>>>> for
>>>>> ambiguity, but I think the intent is that even in this case, the
>>>>> invalidation "sticks". I believe things happen in this sequence: 1)
>>>>> element is destroyed, which automatically invalidates pointers to
>>>>> it; 2)
>>>>> new element is created in the same place, "resurrecting" the old
>>>>> pointers via [basic.life]/8; 3) the library clause kicks in and
>>>>> invalidates the resurrected pointers once more.
>>>> Well... "sure"? Does this now make std::vector unimplementable in the
>>>> C++ language, as it requires implementation "magic" to perform 3)?
>>> Um, no. A pointer becoming invalid is not something you can detect.
>>> Being invalid means that UB will happen if you try to use it. And UB
>>> could include everything "working" as you would expect.
>>
>>
>> Technically, a pointer being invalid means that it has
>> implementation-defined behavior to do anything but dereference it [0],
>> so if an implementaion defined 'copying any invalid pointer prints "stop
>> it" to stdout", then an implementation that did not actually cause
>> pointers to become invalid on vector reallocation would have observably
>> different behavior than one that did (of course, such an implementation
>> could be made conforming by changing the implementation-defined
>> behavior).
>
> You mean when [vector.modifiers] says that pointers are invalidated, it
> means storing
> https://timsong-cpp.github.io/cppwp/n4861/basic.compound#def:value,invalid_pointer
> into each such pointer?

No, there is no need to change the bits of the pointer, the system could
instead unmap the memory the pointer used to refer to.