<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 3689: num_get overflow determination unclear and incorrect</title>
<meta property="og:title" content="Issue 3689: num_get overflow determination unclear and incorrect">
<meta property="og:description" content="C++ library issue. Status: New">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue3689.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#New">New</a> status.</em></p>
<h3 id="3689"><a href="lwg-active.html#3689">3689</a>. <code>num_get</code> overflow determination unclear and incorrect</h3>
<p><b>Section:</b> 28.3.4.3.2.3 <a href="https://wg21.link/facet.num.get.virtuals">[facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2022-03-28 <b>Last modified:</b> 2022-05-17</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all other</b> <a href="lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
28.3.4.3.2.3 <a href="https://wg21.link/facet.num.get.virtuals">[facet.num.get.virtuals]</a> stage 3 specifies that "by the rules of" various <code>strto*</code> functions, 
sequences of chars are converted to a numeric value (producing the "converted value" that is referred to).
<p/>
It then goes on to specify various error cases when the "field represents a value" that is outside the range 
of representable values. Clearly, the value that would be returned from the appropriate <code>strto*</code> function 
is not outside the range of representable values for <code>long long</code>, <code>unsigned long long</code>, <code>float</code>, 
<code>double</code>, and <code>long double</code>; therefore (unless if we expect no range-related errors for those types), 
the field "represents a value" other than the "converted value".
<p/>
Issue 1: It is too subtle to have two distinct values without calling more attention to them by giving them names 
aside from the prose descriptions.
<p/>
If the field "represents" a value other than the value that would be returned from the appropriate <code>strto*</code> 
function, then what value does the field "represent"?
Note that, strictly speaking, it is the process that results in the converted value that the wording says is obtained 
"by the rules of" the <code>strto*</code> functions, which is not the same thing as saying that the value represented is 
interpreted "by the rules of" the <code>strto*</code> functions.
<p/>
If the field "represents" the mathematical value, then for unsigned integer types, all negative values cannot be 
represented. This does not match existing practice.
<p/>
If negative integer values are interpreted using the rules of the <code>strto*</code> functions by obtaining the 
magnitude and then having it "negated (in the return type)", then the return type of <code>strtoull</code> is 
<code>unsigned long long</code>, meaning (where <code>unsigned long long</code> is 64-bit) that "<code>-18446744073709551615</code>" 
is <code>1</code> (even when converting to unsigned integer types of less width). That does not match existing practice.
It is also worth noting that negating in the return type does not work well if the magnitude is not representable as 
a positive value in the return type (e.g., for signed integer types and their most negative representable values).
<p/>
Issue 2: The effect of the minus sign with respect to unsigned integer types can reasonably be interpreted in ways 
that do not match existing practice (and are presumably unintended). The interpretation that works better for 
<code>unsigned long long</code> does not work as well for <code>signed long long</code>.
<p/>
If the field does not "represent" the mathematical value, then for floating-point types, it is unclear whether 
the minus sign takes effect before or after any possible rounding. For literals, the minus sign takes effect after 
rounding.
<p/>
Issue 3: The effect of the minus sign with respect to floating-point types is unclear.
<p/>
Lastly, for floating-point types with signed infinities, there are no finite values outside the range of 
representable values; therefore, conversions of all finite values to such types are specified to "succeed". That 
does not match existing implementation practice.
<p/>
Issue 4: The conditions for identifying range-related errors for conversions to floating-point types do not match 
the conditions that constitute overflow for floating-point types. There is implementation divergence: libc++ appears 
to check for floating-point overflow; libstdc++ appears to check for infinities.
</p>

<p><i>[2022-05-17; Reflector poll]</i></p>

<p>
Set priority to 3 after reflector poll.
</p>



<p id="res-3689"><b>Proposed resolution:</b></p>





</body>
</html>
