C++ Logo

sg14

Advanced search

Re: [SG14] [isocpp-parallel] (SC22WG14.16350) Rough notes from SC22 WG21 SG14 meeting on pointer lifetime-end zap

From: Niall Douglas <s_sourceforge_at_[hidden]>
Date: Thu, 2 May 2019 10:18:49 +0100
>> I think we need pointer values to gain a new treatment during pointed-at
>> invalidation: they get converted to some bunch of stable bits which are
>> not indeterminate, but are also not dereferenceable.
>
> The provenance proposals automatically make them not dereferencable,
> without needing to change the pointer values themselves.

Sure. But I specifically want to retain the ability for pointer values
to the same storage not having, necessarily, the same bit
representation. I particularly want it to be possible that this sequence
of code is valid and possible:

alignas(T) char buffer[sizeof(T)];
T *a = new(buffer) T;
a->~T();
T *b = new(buffer) T;

// Bit representation is different
assert(0 != memcmp(&a, &b, sizeof(&a));

// But pointers compare equal, if provenance proposals are chosen that
// this should be the case
assert(a == b);

The utility of this is that pointers could retain a version counter,
such that we can detect, at runtime, whether dereferencing a pointer to
a dead object is occurring. I think this would be extremely valuable in
a future C or C++ implementation, if CPU hardware adds some acceleration
for this kind of invalid pointer dereference checking.

>> The bunch of stable
>> bits chosen may not be the bits for a valid pointer value, but should
>> still uniquely identify the storage it used to point to.
>>
>> The really hard question is how an invalidated pointer with provenance A
>> ought to be comparable to an invalidated pointer with provenance B?
>
> The straightforward thing semantically would be to make all pointer equality
> comparisons provenance-blind.

Is this proposal not equivalent to always performing a runtime check of
pointer values?

So, specifically, the compiler cannot statically assume that pointer
values are equivalent or dissimilar based on non-value considerations?

Niall

Received on 2019-05-02 04:20:40