Constructor taking 64-bit integer missing on (some) Windows C++ compilers

Vincent Lefevre vincent at
Mon Jun 8 21:11:36 UTC 2020

On 2020-06-08 22:32:25 +0200, Marc Glisse wrote:
> On Sat, 6 Jun 2020, Mihai Preda wrote:
> > At this point the C++ compiler on windows (where long is 32-bit)
> > reports errors, see at the end. The problem is that the set of
> > constructors does not include one taking a 64-bit integer:
> The issue is that:
> 1) the C++ interface follows the C interface
> 2) the C interface is still C89 (no long long)
> 3) Microsoft chose an absurd ABI for win64 (32bit long)
> 3) is unlikely to change, we could change 1) but I'd rather not. The most
> likely evolution is about 2), at some indeterminate point in the future
> (hopefully not too far).

Couldn't the C interface *optionally* support more than C89?

> On Sat, 6 Jun 2020, Vincent Lefevre wrote:
> > There's the same issue with 32-bit architectures, whatever the OS.
> Indeed. And many users would also appreciate interoperability with
> int128_t (or whatever name it uses on their platform).

But isn't the support for 128-bit integers incomplete (i.e. not all
operations required by ISO C for an integer type are implemented)?

> > I would rather suggest to support intmax_t and uintmax_t.
> That's one possibility for C (and C++, although it is a bit more painful
> there), but not one that everyone agrees with. I think the majority in
> standard committees believes that those 2 types were a mistake, in
> particular because they are 64 bits on platforms that now have a 128 bit
> type, but cannot change intmax_t as that would break the ABI.

I think that the first reason is that the support for 128-bit integers
is incomplete.

> Still, it isn't a bad choice for a large builtin integer type.

Anyway you don't introduce a new large builtin integer type everyday.
ABI breakages are annoying, but when they are rare, this could be
acceptable. Moreover, I suspect that very few libraries/applications
would be affected by a change of (u)intmax_t. And these are those
that would benefit from such a change.

Vincent Lefèvre <vincent at> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

More information about the gmp-bugs mailing list