C++ Logo

SG12

Advanced search

Subject: Re: [ub] C provenance semantics proposal
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-04-10 12:08:39


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?

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


SG12 list run by herb.sutter at gmail.com