long long

[Marc Glisse]

On Tue, 31 Jul 2012, Patrick Pelissier wrote:

>>> 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.
>
> Do you have an example of such a platform?

Say, MS visual studio up to version 9 maybe? (I don't have it here to 
check)

>> 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).
>
> Well according to PR#49595, __int128 is not even an extended integer
> type but something strange which can hold an integer of 128 bits.
> Since the C standard doesn't apply (since it is not an extended nor
> standard integer tyoe) and since GCC Manual doesn't specify what
> operations are valid and what are not, I am not even sure what a+b
> does when a and b are __int128 :)

The reason __int128 is documented as "not an extended integer type" is 
precisely so they don't have to make intmax_t a typedef to it and break 
the ABI. Doesn't sound so great...

Note that there are patches floating aroung to introduce __int256 and 
larger types. Possibly on demand (user would just write a typedef with a 
suitable attribute to define a new extended integer type).

>> intmax_t started from a good intention, but it seems fairly useless in
>> practice.
>
> I rarely used long long but used intmax_t  quite often. I found "long
> long" quite useless: either you need 64 bits arithmetic, and you
> should use int64_t (or its friends) to have the optimal type,

Probably int_least64_t or int_fast64_t, in theory.

> or you need the type which can fit them all, and you should use intmax_t.

which, on every platform I met where it was present, is a typedef for long 
long. I agree that intmax_t is nice in theory, but I haven't seen practice 
catch up yet.

Ok, now I've criticized intmax_t enough, I think mpfr's set of *_[su]j 
functions is a fine interface, and I would be happy to see the same in gmp 
;-)

-- 
Marc Glisse