<div dir="ltr"><div dir="ltr">On Wed, Apr 10, 2019 at 6:28 PM Jens Maurer &lt;<a href="mailto:Jens.Maurer@gmx.net">Jens.Maurer@gmx.net</a>&gt; 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>&gt; On Wed, 10 Apr 2019 23:40:37 +0200 Jens Maurer &lt;<a href="mailto:Jens.Maurer@gmx.net" target="_blank">Jens.Maurer@gmx.net</a>&gt; wrote:<br>&gt;&gt;&gt; Inter-object equality comparison has to be supported,<br>
&gt;&gt;<br>
&gt;&gt; &quot;Supported&quot; in the sense of &quot;getting a well-defined, stable answer&quot;,<br>
&gt;&gt; I presume. Why do you need that?<br>
&gt;<br>
&gt; Because this is all that pointer equality is about.  I have to be able<br>
&gt; to compare pointers to whatever objects for equality. If I can only<br>
&gt; use it for pointers for which I know that they point to the same<br>
&gt; object, I don&#39;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 &gt; 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++&#39;s std::string</a> and <a href="https://github.com/llvm-mirror/libcxx/blob/master/include/functional#L1732">libc++&#39;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&#39;s good that this &quot;provenance&quot; work doesn&#39;t propose to change this aspect of C/C++.</div><div><br></div><div>However, I do notice that the above idiom usually doesn&#39;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&#39;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">&gt;&gt; It seems odd to desire support for equality comparisons, but not<br>
&gt;&gt; relational ones.<br>
&gt;<br>
&gt; Why would that be odd? Relational comparison is much more complex, it<br>
&gt; assumes a totally ordered address space. Not all architecture have<br>
&gt; that naturally.<br>
<br>
So, let&#39;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 &quot;totally ordered,&quot; I picture an address space something like what Cerberus displays graphically: it&#39;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&#39;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&#39;t know. But the &quot;bunch of boxes floating in space&quot; addressing model is really easy to imagine and draw on a whiteboard, so I think I understand why it&#39;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">
&gt; C is supposed to work on a much larger set of architectures than POSIX,<br>
&gt; even `uintptr_t` is an optional type in C.<br>
<br>
I continue to be slightly puzzled by the insistent mention of &quot;C&quot;<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&#39;t think it&#39;s odd that the WG14 people in this thread talk about &quot;C&quot;, any more than I think it&#39;s odd that you and I talk about &quot;C++&quot;. 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>