<html>
    <head>
      <base href="https://llvm.org/bugs/" />
    </head>
    <body><span class="vcard"><a class="email" href="mailto:jonathan.sauer@gmx.de" title="jonathan.sauer@gmx.de">jonathan.sauer@gmx.de</a>
</span> changed
              <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED INVALID - int32_t vs. int64_t vs. long ambiguity"
   href="https://llvm.org/bugs/show_bug.cgi?id=23404">bug 23404</a>
        <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">Status</td>
           <td>REOPENED
           </td>
           <td>RESOLVED
           </td>
         </tr>

         <tr>
           <td style="text-align:right;">Resolution</td>
           <td>---
           </td>
           <td>INVALID
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED INVALID - int32_t vs. int64_t vs. long ambiguity"
   href="https://llvm.org/bugs/show_bug.cgi?id=23404#c3">Comment # 3</a>
              on <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED INVALID - int32_t vs. int64_t vs. long ambiguity"
   href="https://llvm.org/bugs/show_bug.cgi?id=23404">bug 23404</a>
              from <span class="vcard"><a class="email" href="mailto:jonathan.sauer@gmx.de" title="jonathan.sauer@gmx.de">jonathan.sauer@gmx.de</a>
</span></b>
        <pre>(In reply to <a href="show_bug.cgi?id=23404#c2">comment #2</a>)
<span class="quote">> The behavior just seems very inconsistent. The overloads work for all signed
> integral types, except for 'long', even though there's a perfect match for
> that type (ie. std::int64_t). For example a short(123) matches std::int32_t
> without problems even though it's not even the same size. In summary:

>     foo(char(123)); // Ok, matches std::int32_t
>     foo(short(123)); // Ok, matches std::int32_t</span >

I'm guessing this is because "char" and "short" are promoted to "int", see C++
Standard §4.5 (Integral promotions).

<span class="quote">>     foo(123); // Ok, matches std::int32_t
>     foo(123L); // Ambiguous
>     foo(123LL); // Ok, matches std::int64_t

> The thing is, there seems to be no portable way of supporting all of those
> types without the calling code needing to do an explicit cast with that one
> single exception, if the interface needs to handle integers of explicit size.</span >

There is: The macros INT32_C, UINT32_C, INT64_C, UINT64_C etc.

<span class="quote">> Adding an overloaded version for 'long' works with clang, but will it work
> with other compilers? Potentially not. There is no way of adding an overload
> that matches 'long' without it potentially clashing with the other overloads
> in some compiler.</span >

True. If you use the std::intXX_t types in function overloading, you must only
use those types.

<span class="quote">> Is there an actual reason (ie. stated in the C++ standard) that a 64-bit
> 'long' can't perfectly match std::int64_t, even though both are signed
> 64-bit integers? (And, likewise, a 32-bit 'long' would match std::int32_t,
> as they are both identical.)</span >

"long" and "int" are different types, as are "long long" and "long". They can
be implicitly converted (C++ Standard §4.7, Integral conversions), but the
conversion of "long" to "int" is as good as the conversion to "long long",
irregardless of their size (otherwise the same code would compile or not
depending on the integer sizes of the target platform). So the call of "foo"
with an argument of type "long" is ambiguous. See C++ Standard §10
(Overloading) and more specifically §13.3.3.1 (Implicit conversion sequences).

Maybe this StackOverflow question helps clarify things further:
<a href="http://stackoverflow.com/questions/10579544/">http://stackoverflow.com/questions/10579544/</a></pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>