Subject: Re: [isocpp-parallel] (SC22WG14.16350) Rough notes from SC22 WG21 SG14 meeting on pointer lifetime-end zap
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-05-02 03:58:32
On 02/05/2019 07:50, Jens Maurer via SG14 wrote:
> So, we seem to be in violent agreement that the current rule of
> invalidating a pointer value system-wide once the heap storage
> it points to is freed is not a good rule: People don't actually
> observe it when programming, and it makes certain algorithms near-
> impossible to implement (uintptr_t is not available unconditionally).
Why are pointers to heap storage any different to pointers to any storage?
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 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? So,
T *a = new T;
T *b = new T;
// Everybody agrees the compiler can assume this is always true
assert(a != b);
// What happens here? Can the compiler assume this is true, or
// false, or is the compiler required to always do a runtime check?
assert(a != b);
The safest approach is to require runtime checking for all pointer
comparisons involving invalidated pointer values.
SG14 list run by email@example.com
Older Archives on Google Groups