Hi Niall,

On 10/04/2019, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> Peter wrote:
>
>>> Now p's provenance is x's storage instance, so comparing it to q is now
>>> a comparison of dissimilar provenance, which is UB.
>>
>> I'm not sure why you think this is different to the example above.
>> An equality (== or !=) comparison between pointers to different storage
>> instances is not UB (in current ISO C and in the new proposal), and
>> if you run this in Cerberus you'll see basically the same as the above.
>
> Thanks for the correction.
>
> Jens wrote:
>
>> We are not inventing anything here, this is what the current C
>> standard states. We have a very simple obligation: equality of
>> representation (`memcmp`) implies equality by type (`==`). Almost all
>> usage of the concept of equality in C is build around this, e.g
>> `atomic_compare_exchange_weak` crucially builds on that property.
>>
>> And I think this is also good that we don't leave things unspecified,
>> here. `==` should be a valid operation between all addresses and
>> provide an equivalence relation.
>
> Sure. C++ special-cases comparisons of nullptr_t, pointers just after
> the end of a storage instance, and pointers to member objects of
> unrelated types. So I would conclude that C++ already implements most of
> your proposal, we just need to flip a few "unspecified"'s into a
> required result, and I think we would implement all of your proposal?

I'll repeat that the semantics of == comparison is a small part of what's going
on here - the main part is the definition of when accesses via pointers
are defined or not, including the cases where those pointers are created
via integer-to-pointer casts, representation-byte manipulation, etc.
I suspect ISO C++ is not clear about those, but I'm not tracking
the C++ standard or the WG21 papers about this closely.

If someone who *is* very familiar with those could go through all the
examples in this note and say whether C++ has the same, different, or
unclear semantics, that'd be really helpful.

Likewise, if compiler developers could go through the examples and say
whether their compiler would be sound (or could reasonably be made
sound) with respect to the proposal, that'd also be really helpful.

best,
Peter

> The next question is whether flipping those unspecified's would be wise
> or not in the context of C++. That's a much harder question to answer,
> but I guess one ought to take each on a case by case basis. For example,
> two unrelated types of identical layout probably could allow member
> variable pointer comparison, but would it be wise to so constrain layout
> in this way?
>
> Niall
>