<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 501: Proposal: strengthen guarantees of lib.comparisons</title>
<meta property="og:title" content="Issue 501: Proposal: strengthen guarantees of lib.comparisons">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue501.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#NAD">NAD</a> status.</em></p>
<h3 id="501"><a href="lwg-closed.html#501">501</a>. Proposal: strengthen guarantees of lib.comparisons</h3>
<p><b>Section:</b> 99 [depr.base] <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Me &lt;anti_spam_email2003@yahoo.com&gt; <b>Opened:</b> 2005-06-07 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#depr.base">issues</a> in [depr.base].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<blockquote><p>
"For templates greater, less, greater_equal, and less_equal,
the specializations for any pointer type yield a total order, even if
the built-in operators &lt;, &gt;, &lt;=, &gt;= do not."
</p></blockquote>

<p>
The standard should do much better than guarantee that these provide a
total order, it should guarantee that it can be used to test if memory
overlaps, i.e. write a portable memmove. You can imagine a platform
where the built-in operators use a uint32_t comparison (this tests for
overlap on this platform) but the less&lt;T*&gt; functor is allowed to be
defined to use a int32_t comparison. On this platform, if you use
std::less with the intent of making a portable memmove, comparison on
an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give
incorrect results.
</p>


<p id="res-501"><b>Proposed resolution:</b></p>
<p>
Add a footnote to 20.5.3/8 saying:
</p>

<blockquote><p>
Given a p1 and p2 such that p1 points to N objects of type T and p2
points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),
less returns the same value when comparing all pointers in [p1,p1+N) to
all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R
such that less returns the same value when comparing all pointers in
[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when
comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).
For the sake of completeness, the null pointer value (4.10) for T is
considered to be an array of 1 object that doesn't overlap with any
non-null pointer to T. less_equal, greater, greater_equal, equal_to,
and not_equal_to give the expected results based on the total ordering
semantics of less. For T of void, treat it as having similar semantics
as T of char i.e. less&lt;cv T*&gt;(a, b) gives the same results as less&lt;cv
void*&gt;(a, b) which gives the same results as less&lt;cv char*&gt;((cv
char*)(cv void*)a, (cv char*)(cv void*)b).
</p></blockquote>

<p>
I'm also thinking there should be a footnote to 20.5.3/1 saying that if
A and B are similar types (4.4/4), comp&lt;A&gt;(a,b) returns the same value
as comp&lt;B&gt;(a,b) (where comp is less, less_equal, etc.). But this might
be problematic if there is some really funky operator overloading going
on that does different things based on cv (that should be undefined
behavior if somebody does that though). This at least should be
guaranteed for all POD types (especially pointers) that use the
built-in comparison operators.
</p>



<p><b>Rationale:</b></p>
<p>
less is already required to provide a strict weak ordering which is good enough
to detect overlapping memory situations.
</p>





</body>
</html>
