long long

Marc Glisse marc.glisse at inria.fr
Tue Jul 31 09:51:00 CEST 2012

On Tue, 31 Jul 2012, Patrick Pelissier wrote:

> On Mon, Jul 30, 2012 at 10:53 PM, Niels Möller <nisse at lysator.liu.se> wrote:
>> Torbjorn Granlund <tg at gmplib.org> writes:
>>> We could perhaps add a parallel set of functions (_ul, or _ull) allowing
>>> long long.  We should then follow the principle of "one GMP release, one
>>> GMP API" and reject compilers and ABIs without long long support.
>> I don't see much harm in making those long long features conditional on
>> some configure test. If a program attempts to use those feature and is
>> compiled with a compiler which doesn't support long long, then it's
>> going to fail anyway, for other reasons than gmp.
> Why not intmax_t / uintmax_t instead of long long / unsigned long long?

I believe every platform that has intmax_t also has long long, but the 
converse is not true.

Some platforms provide types larger that intmax_t (intmax_t is part of the 
ABI, and they couldn't change it when they added a longer type, see for 
instance __int128 in gcc).

intmax_t started from a good intention, but it seems fairly useless in 

Note that if we were in C++, we could probably use template functions and 
avoir having to specify what types are legal.

Marc Glisse

More information about the gmp-devel mailing list