<div dir="ltr"><div dir="ltr">On Wed, Apr 10, 2019 at 6:28 PM Jens Maurer <<a href="mailto:Jens.Maurer@gmx.net">Jens.Maurer@gmx.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 11/04/2019 00.06, Jens Gustedt wrote:<br>> On Wed, 10 Apr 2019 23:40:37 +0200 Jens Maurer <<a href="mailto:Jens.Maurer@gmx.net" target="_blank">Jens.Maurer@gmx.net</a>> wrote:<br>>>> Inter-object equality comparison has to be supported,<br>
>><br>
>> "Supported" in the sense of "getting a well-defined, stable answer",<br>
>> I presume. Why do you need that?<br>
><br>
> Because this is all that pointer equality is about. I have to be able<br>
> to compare pointers to whatever objects for equality. If I can only<br>
> use it for pointers for which I know that they point to the same<br>
> object, I don't a need a `==` operator in the language :)<br>
<br>
Not quite. It does make sense to compare pointers to subobjects<br>
within the same larger object,</blockquote><div><br></div><div>And also to compare pointers to different objects.</div><div><br></div><div> void somefunc(int n) {</div><div> char local_buffer[100];</div><div> char *p = (n > 100 ? malloc(n) : local_buffer);</div><div> use(p);</div><div> if (p != local_buffer) free(p);</div><div> }<br></div><div><br></div><div>This idiom is supported by standard C and C++ today (that is, equality comparison of arbitrary pointers is supported today), and there is lots of code in the wild that relies on this idiom continuing to work. (<a href="https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/basic_string.h#L222">libstdc++'s std::string</a> and <a href="https://github.com/llvm-mirror/libcxx/blob/master/include/functional#L1732">libc++'s std::function</a>, for example. But also a lot of industry code.) Any proposal to change C/C++ so that this idiom stops working would be a non-starter IMHO. So it's good that this "provenance" work doesn't propose to change this aspect of C/C++.</div><div><br></div><div>However, I do notice that the above idiom usually doesn't require that equality comparison work for pointers of different provenance. We just require that malloc(n) <i>never</i> compare equal to local_buffer, and local_buffer <i>always</i> compare equal to local_buffer. We don't, like, serialize the pointer down into a uintptr_t or a text file and then read it back in and <i>then </i>try to compare it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">>> It seems odd to desire support for equality comparisons, but not<br>
>> relational ones.<br>
><br>
> Why would that be odd? Relational comparison is much more complex, it<br>
> assumes a totally ordered address space. Not all architecture have<br>
> that naturally.<br>
<br>
So, let's talk about segmented 16-bit mode of Intel 8086, where<br>
an object is at most 64 KB (one segment).<br></blockquote><div><br></div><div>Intel still has a completely linear address-space; it just represents those addresses in a weird redundant way at the bit level.</div><div><br></div><div>When we talk about an address-space that is not "totally ordered," I picture an address space something like what Cerberus displays graphically: it's just a bunch of boxes floating in space, some of which are guaranteed to be vertically contiguous (that is, ordered) and some of which aren't.</div><div>Does my mental model correspond to some real-world heterogeneous/distributed/associative memory that actually exists, or will exist in the next 40 years? I honestly don't know. But the "bunch of boxes floating in space" addressing model is really easy to imagine and draw on a whiteboard, so I think I understand why it's the model that C and C++ use.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> C is supposed to work on a much larger set of architectures than POSIX,<br>
> even `uintptr_t` is an optional type in C.<br>
<br>
I continue to be slightly puzzled by the insistent mention of "C"<br>
given that one recipient of the e-mail traffic is a WG21 study group.<br>
Ignoring the C++ status quo in this area</blockquote><div><br></div><div>I don't think it's odd that the WG14 people in this thread talk about "C", any more than I think it's odd that you and I talk about "C++". Remember that status quo goes both ways: C++ has borrowed a fair bit from C, too. ;)</div><div><br></div><div>–Arthur</div></div></div>