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.
More information about the gmp-devel