On 2021-06-23 at 09:40, language.lawyer--- via Std-Discussion wrote:
> On 23/06/2021 10:06, Bo Persson via Std-Discussion wrote:
>> 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.
> I'm asking about C++ abstract machine behavior, not about how it may be
> implemented.

In the abstract machine the pointer just becomes invalid when the
pointed-to object goes away. That doesn't require the pointer itself to
change in any other way.

The possibility of an unmapped memory page or segment is just one reason
for the existence of this rule.