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,
in code:

T *a = new T;
delete a;
T *b = new T;

// Everybody agrees the compiler can assume this is always true
assert(a != b);

delete 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.

Niall