<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2735: std::abs(short), std::abs(signed char) and others should return int instead of 
double in order to be compatible with C++98 and C</title>
<meta property="og:title" content="Issue 2735: std::abs(short), std::abs(signed char) and others should return int instead of 
double in order to be compatible with C++98 and C">
<meta property="og:description" content="C++ library issue. Status: C++17">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2735.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#C++17">C++17</a> status.</em></p>
<h3 id="2735"><a href="lwg-defects.html#2735">2735</a>. <code>std::abs(short)</code>, <code>std::abs(signed char)</code> and others should return <code>int</code> instead of 
<code>double</code> in order to be compatible with C++98 and C</h3>
<p><b>Section:</b> 29.7 <a href="https://wg21.link/c.math">[c.math]</a> <b>Status:</b> <a href="lwg-active.html#C++17">C++17</a>
 <b>Submitter:</b> J&ouml;rn Heusipp <b>Opened:</b> 2016-06-16 <b>Last modified:</b> 2017-07-30</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++17">C++17</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider this C++98 program:
</p>
<blockquote>
<pre>
#include &lt;cmath&gt;
#include &lt;cstdlib&gt;

int main() {
  return std::abs(static_cast&lt;short&gt;(23)) % 42;
}
</pre>
</blockquote>
<p>
This works fine with C++98 compilers. At the <code>std::abs(short)</code> call, short gets promoted to <code>int</code> and 
<code>std::abs(int)</code> is called.
<p/>
C++11 added the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4594.pdf">following wording</a>
on page 1083 &sect;26.9 p15 b2 [c.math]:
</p>
<blockquote>
<p>
Otherwise, if any argument of arithmetic type corresponding to a <code>double</code> parameter has type <code>double</code> 
or an integer type, then all arguments of arithmetic type corresponding to <code>double</code> parameters are effectively 
cast to <code>double</code>.
</p>
</blockquote>
<p>
C++17 draft <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4594.pdf">additionally adds</a> on
page 1080 &sect;26.9 p10 [c.math]:
</p>
<blockquote>
<p>
If <code>abs()</code> is called with an argument of type <code>X</code> for which <code>is_unsigned&lt;X&gt;::value</code> is <code>true</code> 
and if <code>X</code> cannot be converted to <code>int</code> by integral promotion (4.5), the program is ill-formed. [<i>Note:</i> 
Arguments that can be promoted to <code>int</code> are permitted for compatibility with C. &mdash; <i>end note</i>]
</p>
</blockquote>
<p>
It is somewhat confusing and probably even contradictory to on the one hand specify <code>abs()</code> in terms of integral 
promotion in &sect;26.9 p10 and on the other hand demand all integral types to be converted to <code>double</code> in 
&sect;26.9 p15 b2.
<p/>
Most compilers (each with their own respective library implementation) I tested (MSVC, Clang, older GCC) appear to not 
consider &sect;26.9 p15 b2 for <code>std::abs</code> and compile the code successfully. GCC 4.5-5.3 (for <code>std::abs</code> but 
not for <code>::abs</code>) as well as GCC &gt;=6.0 (for both <code>std::abs</code> and <code>::abs</code>) fail to compile in the following 
way: Taking &sect;26.9 p15 b2 literally and applying it to <code>abs()</code> (which is listed in &sect;26.9 p12) results in 
<code>abs(short)</code> returning <code>double</code>, and with <code>operator%</code> not being specified for <code>double</code>, this 
makes the programm ill-formed.
<p/>
I do acknowledge the reason for the wording and semantics demanded by &sect;26.9 p15 b2, i.e. being able to call math functions 
with integral types or with partly floating point types and partly integral types. Converting integral types to <code>double</code>
certainly makes sense here for all the other floating point math functions.
However, <code>abs()</code> is special. <code>abs()</code> has overloads for the 3 wider integral types which return integral types. 
<code>abs()</code> originates in the C standard in <code>stdlib.h</code> and had originally been specified for integral types only. 
Calling it in C with a short argument returns an <code>int</code>. Calling <code>std::abs(short)</code> in C++98 also returns an 
<code>int</code>. Calling <code>std::abs(short)</code> in C++11 and later with &sect;26.9 p15 b2 applied to <code>abs()</code> suddenly 
returns a <code>double</code>.
<p/>
Additionally, this behaviour also breaks third-party C headers which contain macros or inline functions calling 
<code>abs(short)</code>.
<p/>
As per discussion on std-discussion, my reading of the standard as well as GCC's interpretation seem valid.
However, as can be seen, this breaks existing code.
<p/>
In addition to the compatibilty concerns, having <code>std::abs(short)</code> return <code>double</code> is also very confusing 
and unintuitive.
<p/>
The other (possibly, depending on their respective size relative to <code>int</code>) affected types besides <code>short</code> 
are <code>signed char</code>, <code>unsigned char</code> and <code>unsigned short</code>, and also <code>char</code>, <code>char16_t</code>, 
<code>char32_t</code> and <code>wchar_t</code>, (all of these are or may be promotable to <code>int</code>). Wider integral types 
are not affected because explicit overloads are specified for those types by &sect;26.9 p6, &sect;26.9 p7 and &sect;26.9 p9.
<code>div()</code> is also not affected because it is neither listed in &sect;26.9 p12, nor does it actually provide 
any overload for <code>double</code> at all.
<p/>
As far as I can see, the proposed or implemented solutions for LWG <a href="lwg-defects.html#2294" title="&lt;cstdlib&gt; should declare abs(double) (Status: Resolved)">2294</a><sup><a href="https://cplusplus.github.io/LWG/issue2294" title="Latest snapshot">(i)</a></sup>, <a href="lwg-defects.html#2192" title="Validity and return type of std::abs(0u) is unclear (Status: C++17)">2192</a><sup><a href="https://cplusplus.github.io/LWG/issue2192" title="Latest snapshot">(i)</a></sup> and/or 
<a href="lwg-defects.html#2086" title="Overly generic type support for math functions (Status: C++14)">2086</a><sup><a href="https://cplusplus.github.io/LWG/issue2086" title="Latest snapshot">(i)</a></sup> do not resolve this issue.
<p/>
I think both, &sect;26.9 p10 [c.math] and &sect;26.9 p15 [c.math] need some correction and clarification.
<p/>
(Note: These changes would explicitly render the current implementation in GCC's libstdc++ non-conforming, which would 
be a good thing, as outlined above.)
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to N4594.</p>
<ol>
<li><p>Modify 29.7 <a href="https://wg21.link/c.math">[c.math]</a> as indicated:</p>

<blockquote>
<p>
-10- If <code>abs()</code> is called with an argument of type <code>X</code> for which <code>is_unsigned&lt;X&gt;::value</code> is 
<code>true</code> and if <code>X</code> cannot be converted to <code>int</code> by integral promotion (4.5), the program is ill-formed.
<ins>If <code>abs()</code> is called with an argument of type <code>X</code> which can be converted to <code>int</code> by integral 
promotion (4.5), the argument is promoted to <code>int</code>.</ins> [<i>Note:</i> Arguments that can be promoted to <code>int</code> 
are <ins>promoted to <code>int</code> in order to keep</ins><del>permitted for</del> compatibility with C. &mdash; <i>end note</i>]
<p/>
[&hellip;]
<p/>
-15- Moreover, there shall be additional overloads <ins>for these functions, with the exception of <code>abs()</code>,</ins> 
sufficient to ensure:
</p>
<ol>
<li><p>If any argument of arithmetic type corresponding to a <code>double</code> parameter has type <code>long double</code>, then
all arguments of arithmetic type (3.9.1) corresponding to <code>double</code> parameters are effectively cast to
<code>long double</code>.</p></li>
<li><p>Otherwise, if any argument of arithmetic type corresponding to a <code>double</code> parameter has type <code>double</code>
or an integer type, then all arguments of arithmetic type corresponding to <code>double</code> parameters are
effectively cast to <code>double</code>.</p></li>
<li><p>Otherwise, all arguments of arithmetic type corresponding to <code>double</code> parameters have type <code>float</code>.</p></li>
</ol>
<p>
See also: ISO C 7.5, 7.10.2, 7.10.6.
<p/>
<ins>[<i>Note:</i> <code>abs()</code> is exempted from these rules in order to stay compatible with C. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-07 Chicago]</i></p>

<p>Monday: Some of this has been changed in N4606; the rest of the changes may be editorial.</p>
<p>Fri PM: Move to Tentatively Ready</p>



<p id="res-2735"><b>Proposed resolution:</b></p>
<p>This wording is relative to N4606.</p>
<ol>
<li><p>Modify 29.7.1 <a href="https://wg21.link/cmath.syn">[cmath.syn]</a> as indicated:</p>

<blockquote>
<p>
-2- For each set of overloaded functions within <code>&lt;cmath&gt;</code>,
 <ins>with the exception of <code>abs</code>, </ins> there shall be additional
overloads sufficient to ensure:
</p>
<ol>
<li><p>If any argument of arithmetic type corresponding to a <code>double</code> parameter has type <code>long double</code>, then
all arguments of arithmetic type (3.9.1) corresponding to <code>double</code> parameters are effectively cast to
<code>long double</code>.</p></li>
<li><p>Otherwise, if any argument of arithmetic type corresponding to a <code>double</code> parameter has type <code>double</code>
or an integer type, then all arguments of arithmetic type corresponding to <code>double</code> parameters are
effectively cast to <code>double</code>.</p></li>
<li><p>Otherwise, all arguments of arithmetic type corresponding to <code>double</code> parameters have type <code>float</code>.</p></li>
</ol>
<p><ins>[<i>Note:</i> <code>abs</code> is exempted from these rules in order to stay compatible with C. &mdash; <i>end note</i>]</ins></p>
<p>
See also: ISO C 7.5, 7.10.2, 7.10.6.
</p>
</blockquote>
</li>
</ol>





</body>
</html>
