enable maximum integer type to be 128 bits

[Jan Beulich]

>However, there are two things you need to realize.  First is that
>supporting 128-bit integer types involves nontrivial amounts of
>overhead in the compiler, especially on 32-bit archs.  This is
>something we'd like to fix, but it's a lot of work (we would
basically
>have to switch all of the constant-handling to use something like GMP
>or MPFR - that's not out of the question, but no one has stepped up
to
>the plate).

I don't mean to have support for this on 32-bit archs (as I already
expressed a couple of times). On 64-bit archs, gcc already has almost
all of the required functionality, so no fundamental work is needed.

>Second, 
>
>> (and as I previously said I consider it an error of say glibc to
not
>> make intmax_t 128 bits wide on 64-bit archs in the first place, but
>> this is not the only stdint.h shortcoming in glibc).
>
>to say this indicates that you don't understand why intmax_t is 64
>bits wide on a 64-bit architecture.  The short version is that there
>is a huge amount of code out there in the wild written to the
>following two assumptions:
>
>1) sizeof(size_t) == sizeof(void *)

This perhaps is a fair assumption (I use it myself occasionally, but
each time remembering [and fearing the consequences of] this not being a
guarantee).

>2) sizeof(long) >= sizeof(any standard typedef, especially size_t).

This is not, and never has been. See P64 data models on 64-bit archs
(as used by Windows among others), and also ILP32 ones (where long long
then exceeds pointer width, since C99 requires long long to be at least
64 bits wide, and consequently on such a model intmax_t must also be at
least 64 bits wide, since long long is no doubt a standard integer
type).

>(2) in particular was an ironclad guarantee under C90, which
guarantee
>was silently withdrawn in C99; a lot of people (me included) think
>that this is a catastrophic bug in C99.  Sensible C implementors do
>not take advantage of the bug: 'long' MUST have at least as many
>significant bits as any standard typedef.  In particular, 'intmax_t'
>and 'long' MUST be the same type.

If so, introduction of long long would have been useless (because you'd
imply sizeof(long) >= sizeof(long long), and with the standard requiring
the opposite relation, this results in sizeof(long) == sizeof(long
long)). I strongly believe intmax_t's specifically intended to be able
to exceed any other integral (and pointer) widths... It's a matter of
taste to a certain degree, sure, but me having another taste than you
doesn't mean mine's wrong and must not be allowed.
Further more, and here you definitely have a problem with your model,
for 32-bit archs sizeof(long) never matches sizeof(intmax_t) (since you
want sizeof(long) == sizeof(void*), and you have to have
sizeof(intmax_t) >= sizeof(long long) >= 64).

Jan