On 11/04/2019 00.06, Jens Gustedt wrote:
> Hello Jens,
>
> On Wed, 10 Apr 2019 23:40:37 +0200 Jens Maurer <Jens.Maurer_at_[hidden]>
> wrote:
>
>>> Inter-object equality comparison has to be supported,
>>
>> "Supported" in the sense of "getting a well-defined, stable answer",
>> I presume. Why do you need that?
>
> Because this is all that pointer equality is about. I have to be able
> to compare pointers to whatever objects for equality. If I can only
> use it for pointers for which I know that they point to the same
> object, I don't a need a `==` operator in the language :)

Not quite. It does make sense to compare pointers to subobjects
within the same larger object, e.g.

int a[100];
bool b = &a[5] == &a[6];

where, of course, the pointers may come from more involved
pointer arithmetic.
This is supported and well-defined in the status quo, I presume,
and nobody is suggesting to change that.

So, there is a use and need for == on pointers even if you can't
compare pointers to arbitrary objects.

So, again, why do you need to compare pointers to arbitrary
objects?

>>> though there's some
>>> debate about what the semantics should be in the one-past case -
>>> whether the result should be allowed to be provenance-sensitive or
>>> not.
>>>
>>> Inter-object relational comparison is not allowed in ISO C. Perhaps
>>> that's also debatable, as real code seems to rely on it, but it's
>>> not the main subject of the provenance proposal - probably best not
>>> to go into it right now.
>>
>> It seems odd to desire support for equality comparisons, but not
>> relational ones.
>
> Why would that be odd? Relational comparison is much more complex, it
> assumes a totally ordered address space. Not all architecture have
> that naturally.

So, let's talk about segmented 16-bit mode of Intel 8086, where
an object is at most 64 KB (one segment).
An equality comparison for pointers pointing anywhere within the same object
can simply compare the offset (cheap), whereas supporting equality comparisons
for arbitrary pointers needs normalization to remove the ambiguities
of several segment/offset combinations being able to represent
the same address (more expensive). Which is also what you need to
do for arbitrary relational comparisons.

> C is supposed to work on a much larger set of architectures than POSIX,
> even `uintptr_t` is an optional type in C.

I continue to be slightly puzzled by the insistent mention of "C"
given that one recipient of the e-mail traffic is a WG21 study group.
Ignoring the C++ status quo in this area will likely result in the
usual set of subtle incompatibilities between C and C++ that have
materialized over the decades when one took features from the other.

Jens