[LLVMbugs] [Bug 23404] int32_t vs. int64_t vs. long ambiguity

[bugzilla-daemon at llvm.org]

https://llvm.org/bugs/show_bug.cgi?id=23404

warp at iki.fi changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #2 from warp at iki.fi ---
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
    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.

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.

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.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150504/ae685602/attachment.html>