<div dir="ltr"><div class="gmail_extra">On 17 October 2013 10:19, Gabriel Dos Reis <span dir="ltr">&lt;<a href="mailto:gdr@axiomatics.org" target="_blank">gdr@axiomatics.org</a>&gt;</span> wrote:<br><div class="gmail_quote">


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Nevin Liber &lt;<a href="mailto:nevin@eviloverlord.com" target="_blank">nevin@eviloverlord.com</a>&gt; writes:<br>


<br>
| But, even if segmented architectures, unlikely though it is, do come back, the<br>
| ordering problem still has to be addressed, as std::less&lt;T*&gt; is required to<br>
| totally order pointers.  I just want operator&lt; to be an alternate spelling for<br>
| that property.<br>
<br>
</div>I will repeat this again: std::less&lt;T*&gt; is absolutely not a problem,<br>
because this<br>
<br>
      return intptr_t(p) &lt; intptr_t(q);<br>
<br>
is valid and portable definition that requires no other special handling.<br></blockquote><div><br></div><div>1.  intptr_t is optional (n3797 18.4.1)  Therefore, it isn&#39;t portable.</div><div><br></div><div>2.  The only guarantee I can find about intptr_t is in the C standard (n1570 in their document numbering scheme) 7.20.1.4 Integer types capable of holding object pointers:</div>


<div><br></div><div><p style="margin:0.0px 0.0px 0.0px 0.0px;font:12.0px Helvetica">The following type designates a signed integer type with the property that any valid</p>
<p style="margin:0.0px 0.0px 0.0px 0.0px;font:12.0px Helvetica">pointer to <span style="font:12.0px Times"><b>void </b></span>can be converted to this type, then converted back to pointer to <span style="font:12.0px Times"><b>void</b></span>,</p>



<p style="margin:0.0px 0.0px 0.0px 0.0px;font:12.0px Helvetica">and the result will compare equal to the original pointer:</p>
<p style="margin:0.0px 0.0px 0.0px 0.0px;font:12.0px Times"><b>intptr_t</b></p>
<p style="margin:0.0px 0.0px 0.0px 0.0px;font:12.0px Helvetica"><br></p><p style="margin:0.0px 0.0px 0.0px 0.0px;font:12.0px Helvetica">I see no ordering guarantees.</p></div><div><br></div><div>3.  Let&#39;s say I&#39;m on a 16-bit architecture.  I have an array from address 0x7fff-0x8001.  The obvious conversion doesn&#39;t preserve ordering, as 0x7fff &lt; 0x8001 as addresses but 32767 &gt; -32767 as integers.  This is trivially addressed by moving to the also optional uintptr_t, but then...</div>


<div><br></div><div>4.  I can imagine on a system concerned about security that a process-specific salt is applied to the address when converted to an integer (not dissimilar to that proposed for hashing in n3333).  As long as the process can be reversed, I don&#39;t see anything in the standard which precludes it.  It can be something as simple as adding a fixed offset to the value and ordering is broken.</div>


<div><br></div><div><br></div><div>Again, what should we recommend to this author?  If we are going to tell him to rely on non-portable, non-guaranteed behavior he might as well keep relying on pointers being totally ordered.</div>


</div>-- <br> Nevin &quot;:-)&quot; Liber  &lt;mailto:<a href="mailto:nevin@eviloverlord.com" target="_blank">nevin@eviloverlord.com</a>&gt;  <a href="tel:%28847%29%20691-1404" value="+18476911404" target="_blank">(847) 691-1404</a>
</div></div>