<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 497: meaning of numeric_limits::traps for floating point types</title>
<meta property="og:title" content="Issue 497: meaning of numeric_limits::traps for floating point types">
<meta property="og:description" content="C++ library issue. Status: CD1">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue497.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#CD1">CD1</a> status.</em></p>
<h3 id="497"><a href="lwg-defects.html#497">497</a>. meaning of numeric_limits::traps for floating point types</h3>
<p><b>Section:</b> 17.3.5.2 <a href="https://wg21.link/numeric.limits.members">[numeric.limits.members]</a> <b>Status:</b> <a href="lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-03-02 <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#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>

<blockquote>
<p>static const bool traps;<br/>
-59- true if trapping is implemented for the type.204)
<br/>
Footnote 204: Required by LIA-1.
</p>
</blockquote>

<p>It's not clear what is meant by "is implemented" here.</p>

<p>
In the context of floating point numbers it seems reasonable to expect
to be able to use traps to determine whether a program can "safely" use
infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
without causing a trap (i.e., on UNIX without having to worry about
getting a signal). When traps is true, I would expect any of the
operations in section 7 of IEEE 754 to cause a trap (and my program
to get a SIGFPE). So, for example, on Alpha, I would expect traps
to be true by default (unless I compiled my program with the -ieee
option), false by default on most other popular architectures,
including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
traps to be explicitly enabled by the program.
</p>

<p>
Another possible interpretation of p59 is that traps should be true
on any implementation that supports traps regardless of whether they
are enabled by default or not. I don't think such an interpretation
makes the traps member very useful, even though that is how traps is
implemented on several platforms. It is also the only way to implement
traps on platforms that allow programs to enable and disable trapping
at runtime.
</p>


<p id="res-497"><b>Proposed resolution:</b></p>
<p>Change p59 to read:</p>
<blockquote><p>True if, at program startup, there exists a value of the type that
  would cause an arithmetic operation using that value to trap.</p></blockquote>


<p><b>Rationale:</b></p>
<p>
 Real issue, since trapping can be turned on and off. Unclear what a
 static query can say about a dynamic issue. The real advice we should
 give users is to use cfenv for these sorts of queries. But this new
 proposed resolution is at least consistent and slightly better than
 nothing.</p>





</body>
</html>
